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Tnis  tnesls  presents  tne  specif  icdtion,  lesig'-  anc 
irpie-nentati  on  of  a  prototype  microcomputer  system  for  tne 
target  information  section  of  tne  Yarine  Corps  fire  support 
coorllnation  ''enter.  Currently,  tne  target  information 
section  uses  a  series  of  index  cards,  nandwritten  lists, 
acetate  covers!  battle  maps  an!  erease  pencils  to  perform 
tne  target  information  functions. 

Tne  tnesls  examines  and  analyzes  tnese  functions  in 
detail  and  proposes  a  solution  in  tne  form  of  a  system,  data 
case  and  interactive  user  design.  Tne  resultant 
microcomputer  Systemi  for  Tar?et  Information  tYlSTI)  employs 
an  ALTOS  mlcrcccmputer ,  tne  'JCSD  Pascal  operating 
system,  a  user  friendly  interface  and  data  Dase  tecnnoio?y. 
It  is  proposed  as  an  interim  system  until  tne  ^'arir.e 
Integrated  Fire  and  Air  Support  System  'YIFASS'  becomes 


operational. 


TAiJLS  OF  CONTENTS 


INTP.OrOCTICN . 13 


A.  TEE  PROBLEM! . 13 

B.  BACCG’’0UND . 15 

C.  INTSGRATEE  FIRS  ANC  AIR  SUPPORT  SISTSM . IS 

2.  NATURE  OF  TEE  PFCisLE'l . ly 

E.  NATURE  OF  TEE  SOLUTION . 2L' 

II.  TARGET  INFORMATION  PR0CE2URES  ANT  EMPLOYMENT . 23 

A.  GENERAL . 23 

P.  DUTIES  OF  TEE  TARGET  INFORMATION  OFFICER . 24 

C.  FUNCTIONS  OF  THE  TARGET  INFORMATION  SECTION _ 25 

C.  TAPGET  INFORMATION  RECORDS  AND  FILES . 27 

E.  THE  TARGET  LIST . 30 

F.  TARGET  CLASSIFICATION . 31 

G.  TARGET  PRIORITY . 32 

E.  THE  TARGET  BULLETIN . 33 

I.  OPERATIONS  OF  TEE  TARGET  INFORMATION  SECTION. ..33 

OPERATIONAL  CHARACTERISTICS . 36 

E.  SUMMARY . 37 

III.  SYSTE'^  DESIGN  CONSIDERATIONS . 39 

A.  PRIMARY  considerations . 33 

1.  ParX^round . 33 

2.  TasKS . 42 

B.  THE  USER  INTERFACE . 41 

C.  USER  DESIGN  CRITERIA . 42 


5 


D.  TRE  ^^ICROCQ^:PUTER  ENVIRONMENT . 44 

E.  FUNCTIONS  OF  THE  SYSTEM . 45 

1.  Prltnoiry  Functions . 45 

2.  Display  Options.... . 4b 

3.  Print  Options . 47 

F.  SUMMARY . 47 

17.  SYSTEM  DSSION . 4y 

4.  CONCEPTUAL  SYSTEM  LESION . 43 

1.  Oenerality  of  Approacn . 43 

2.  Data  Base  Considerations . 43 

3.  Applications  Program  Considerations . 5fe: 

B.  PRELIMINARY  CONSIDERATIONS . 51 

C.  HARDWARE  SELECTION . 52 

D.  PROORAMMINO  LANGUAGE  SELECTION . 54 

E.  DATA  BASE  CONSIDERATIONS . 55 

F.  USSR  interface  CONSIDERATIONS . 5« 

0.  APPLICATIONS  PROGRAM  CONSIDERATIONS . 53 

H.  SSCURITT  AND  INTEGRITY . 51 

I.  TRANSITION . 53 

7.  DATA  BASE  DESIGN . 56 

A.  PRELIMINARY  DESIGN  PROCESS . 56 

1.  Data  Base  Concepts . 56 

2.  Data  Base  Terminology . 5B 

3.  File  Determination. . 53 

4.  File  Performance . 7i 

5.  Arcaitectural  Perspective . 7i 

6 


t 

H.  'lenu/Forn  FiXiin^  ?orndttir*«? . ito 

F.  Fr.r. Cf. 

'rii.  APPLIC  AliOi-'J  PROuRAi-l  i'-?LFM£..<TATI 'J.'J . Ill 

A.  SYaTrJ.'i  L'IPL  F.'^Ft',  I  AT  I  Gu . xil 

u.  ri-XHMICAL  CC.'iSirKf.ATlGNS . 11'’ 

tactical  CC.'.S  iLFRATIO.'.i . 11  = 

r.  SYSTF'"  RFFlNi.'^Fi'iTS . l^t 

Till.  CCNCLCSIOnS  AWl.-  R>JCO,'^-''i;Mi}ATIG.'o . l’^;!! 

A.  CONCi-US  lOio . I'ii'd 

S.  RiCOMMtiNLATIOi'jS . ld'6 

APPENDIX  A  — DATA  DICTIGNAf.I . lil-A 

APPENDIX  3— EXAf^PLE  OF  STSTE.-'i  'JSER  INTERAFCE . 1R7 

£I£LI3rjUF»r . lAl 

INITIAL  DISTRIS'JTION  LIST . 144 


b 


1 


1 


.  1 

‘1 

i 

r 


LIST  Oi  rlaURiS 


1.  ix-iTple  Of  a  Tarsei  Cara . 

2 .  Tar»e  i  Ca  rl  i’i  ie  Or»a  ni:a  ti  on . iiy 

3.  Target  List  Terrrinoio#?y . 31 

•i.  System  rssl,-?n  ilnv i ronmen t . 43 

3.  Design  Of  tn?  Conceptual  .'loiei . bl 

fc.  Target  Information  System  Design . c4 

.“iemory  Allocation . bb 

d.  Data  Base  System  Arcnitecture . 73 

D.  Target  Information  Conceptual  P.ecora . 7d 

13.  Primary  and  Secondary  tCeys . 77 

11.  Example  of  a  Target  List . ct, 

12.  Logical  Record  Lesign . rl 

13.  System  Output . 22 

14.  Target  rile  Incex  Design . b3 

lb.  CCSD  Pasr-ai  Random  Access  Capa  oil  ity . r4 

16.  Data  Base  Ouery  File  Logical  Design . c7 

17.  Main  Memory  May  for  Data  Base  wueries . =4 

lb.  Example  of  an  inverted  lile  Logical  Structure . 43 

14.  Data  Dase  ouery  File  Pnysi-'ai  Lesl^n . ^3 

23.  Data  Base  Partitioning . 4b 

21.  Example  of  a  Menu . lidb 

22.  Example  of  an  Error  .Message . 134 


23.  Actual  Secondary  Storaife  Usa-ee 


114 


LIST  Of  AirR27lATI0NS 


AAA - 

ART? - 

ASCII  — 

ASIS - 

BOA - 

C2AT - 

CODASIL- 
CP/V - 


DASC 

TBVS 


n'fl'T 

X  ^ 


FASC 

fCC- 

t'yj'M 


fORT - 


7SC 


fSCC - 

Ijy - 

INST - 

1 - 

^ASTF - 


Anti-Aircraft  Artiiiery  Target 
Artillery  Target 

A.Tierican  Staniard  Code  for  Information  Intercnange 

Ampnitious  Support  Information  System 

Battle  Damage  Assessment 

Counter  Battery  Target 

Conference  on  Data  Systems  Lanffua^es 

Command  Program/I^oni tor;  operating  system  cui i t  ey 
Digital  Researcn  for  'Microcomputers 

Catnode  P.ay  Tuoe 

Direct  Air  Support  Center 

Data  Base  .'Management  System 

Date-Time  Group 

Fire  and  Air  Support  Center 

Fire  Direction  Center 

Fleet  ^''arine  Force  (Manual 

Fortification,  BunSer,  Hardened  Site  Ta r^e t 
Fire  Support  Coordinator 
Fire  Support  Coordination  Center 
International  Business  Macnines  Corporation 
Installation,  Buildings  Target 
kilobyte  (ie24  bytes) 

'Marine  Air-Ground  Tasi  Force 

liS 


I 


'^ISC - 

J  ^ 

fc  A  w  ^  k.- 

NGF - 

N'*'P - 

C? - 

SACC - 

SA'^ - 

SFAP - 

TAR5UL-- 
TERR - 


'^arir.e  Integrated  Fire  and  Air  Support  Syste 
'Miscellaneous  Target 

'Marine  Tactical  Coirnanl  and  Control  Systecs 

Naval  Gunfire 

Naval  Warfare  Fuciication 

Observation  Post  Target 

Supportine  Ams  Coordination  Center 

Surfare-t o-Alr  ^!lssiie  Target 

Suppression  of  Enemy  Air  Defense 

Target  Sulletin 

Terrain  Target  (Hilltop,  Road  Junction,  Fiel 


Ta  rse  t 


TIC - Target  Information  Center  (.Savy^ 

TIO -  Target  Information  Officer 

TIS - Target  Information  Section  (■'•arine) 

OCSD -  University  of  California  at  San  Diego 

VEH -  Tebicular  Target  (Trues,  Jeep,  etc.) 


11 


ACSNOWl.iirSS.'lEMS 


Tne  autnor  wouia  ilte  to  acxnov» leir'-e  tne  assistance  ar.a 
support  of  LtCol  Den  Sortino,  US'^C,  Assistant  lire  Support 
Coordinator  of  tne  Second  Marine  Division,  Canp  Lejeune, 
N'ortn  Carolina  in  providic?  current  information  on  target 
information  procedures  and  Capt  C.  .  Mliier,  CSMC,  of  tne 
Marine  Corps  Tactical  Software  Support  Activity  (MCTSSA^, 
Camp  Pendleton,  California  for  providing  tinely  and  detailed 
information  on  tne  Marine  Integrated  Fire  and  Air  Support 
System  (MIFASS) . 

Tne  ffuidance  and  suggestions  provided  oy  tnesis  advisor. 
Professor  Lyis  A.  Cox,  Jr.  and  first  reader.  Professor  Dusan 
Z.  Badal  are  deeply  appreciated  and  tneir  encouragement  and 
confidence  were  a  constant  source  of  optimism.  Capt  Jeffrey 
A.  Neufeld,  USMC  and  Cpt  A.  Boss  Striciler,  C.S.  Army, 
provided  tecnnical  assistance  in  tne  finer  points  of  tne 
'ICSD  system  and  tneir  assistance  proved  timely  and  valuaoie. 


I.  IMTRODOCTION 


A.  THE  PROBLEM 

More  and  more  of  me  applications  of  modern  amptiioious 
warfare,  from  real-time  combat  systems  to  tne  data  oases 
tnat  control  the  men,  materiel  and  resources  needed  to  wage 
war,  have  turned  to  computerized  solutions.  The  products  of 
the  technological  explosion  nave  enabled  tne  Navy-Marine 
Corps  amphibious  team  to  do  more,  to  do  it  faster  and  to  do 
it  with  a  degree  of  efficiency  and  accuracy  previously 
unobtainable . 

This  evolution  of  modern  tecnnology  nas  not  yet  reacned 
the  Marine  Corps  tactical  command  posts  established  on  me 
beachhead.  The  target  information  section  of  tne  landing 
force  fire  support  coordination  center  (FSCC)  plays  a 
slgnflcant  role  in  tne  conduct  of  effective  coordination  of 
tactical  air,  artillery  ana  naval  gunfire  support  on  targets 
of  high  priority,  fet  the  target  information  officer  and  nis 
staff  accomplish  their  important  lasJc  by  the  use  of  index 
card  files,  cross-reference  files,  hand  written  lists  of 
targets  and  colored  grease  pencils  on  acetate-covered 
tactical  maps.  This  method  is  time  consuming,  slow  in 
response  to  inquires  about  target  information,  tedious  and 
difficult  to  maintain  in  a  current  status  and  does  not 
provide  information  in  a  sufficiently  timely  and  accurate 


16 


manner.  It  Is  40  year  oil  tecanoiogy  In  tne  age  of 
computers . 

Tne  requirement  to  automate  many  of  tne  functions  of  tne 
tactical  command  post  nas  been  Identified  and  tne  command 
post  of  tne  future  is  belne  pianned  for  and  developed  now. 
Until  It  arrlveSt  tnere  is  a  need  to  provide  an  interim 
capability  to  tne  landinsr  force.  An  automated  solution  to 
me  target  information  function  will  simplify  tne  tasic  of 
tne  target  information  section  considera bly ,  will  provide 
rapid,  accurate  and  timely  target  information  to  tne  members 
of  tne  FSCC,  and  can  be  made  operational  now,  five  full 
years  before  tne  planned  Introduction  of  tne  computerized 
command  post, 

Tnls  tnesls  contends  taat  tne  automation  of  tne  target 
information  function  is  necessary  to  improve  tne  operational 
capability  of  tne  landing  force  FSCC  and  tnai  Implementation 
of  a  suitable  and  effective  tareet  information  system  is 
possible.  Tnls  tnesls  will  prove  tnis  contention  by 
implementing  and  designing  a  woricing  prototype  wnicn  will 
increase  operational  effectiveness  immediately  as  well  as 
provide  a  testbed  and  learning  model  for  tne  future 
automated  command  post.  Tlie  prototype  will  be  designed  to 
perform  ail  tne  duties  and  functions  of  tne  target 
information  section  as  currently  stated  in  doctrinal 
publications.  The  interim  system  will  aopefully  contribute 
to  tne  development  of  tne  future  system  and  identify  areas 
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of  concern  and  improvement  before  me  future  Marine  Corps 
system  becomes  operational. 

£.  BiCKGROaND 

An  important  aspect  of  anpnibious  fire  support 
coordination  ( tne  planning  and  execution  of  tactical  air, 
artillery  and  naval  gunfire  support  so  tnat  targets  are 
adequately  covered  by  a  suitable  weapon  or  eroup  or  weapons ^ 
is  tne  function  of  target  information.  One  of  me  major 
duties  of  tne  fire  support  coordinator,  tnat  member  of  the 
landing  force  staff  responsible  for  coordination  of  fire 
support,  is  to  ensure  tnat  tne  fire  support  coordination 
center  receives  and  disseminates  available  target 
information  to  all  staff  sections  and  commands  requiring  the 
information.  He  also  must  worjr  closely  witn  tne  target 
Information  officer  and  tne  commander  and  nls  staff  in  tne 
selection  of  targets  and  assignment  of  classification  and 
attack  priorities. 

Target  Information  Is  tne  direct  application  of  combat 
intelligence  to  fire  support  and  is  a  sey  to  tne  proper 
employment  of  supporting  arms  in  conjunction  wltii  earn  of 
tne  plans  of  the  ampnibious  operation.  Effective  fire 
support  coordination  and  tne  planning  of  amphibious 
operations  generate  a  continuing  requirement  for  target 
acquisition,  dissemination,  evaluation  and  recommendation 
for  attack. 
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To  accotrpllsn  this  important  tasKf  the  commander  of  the 
ampnlblous  tasfc  force  assigns  a  target  Intelligence  officer 
to  the  supporting  arms  coordination  center  (SACO.  This 
officer  operates  tne  target  information  center  (TIC)  and 
worrs  closely  with  tne  air  intelligence  officer,  tne  landing 
force  targeting  representatives  and  the  supporting  arms 
coordinator.  The  commander  of  tne  landlne  force  has  a  target 
Information  officer  (TIO)  wno  operates  tne  target 
Information  section  (TIS)  as  an  integral  part  of  tne  landing 
force  fire  support  coordination  center  and  a  target 
Intelligence  officer  who  functions  in  tne  landing  force 
Intelligence  center. 

The  Navy  staff  uses  a  computerized  target  information 
system  wnicn  is  part  of  tne  snipooard  Ampnlblous  Support 
Information  System  (ASIS)  and  maintains  tne  list  of  targets 
as  part  of  a  data  oase.  Target  information  operations  in  tne 
SACC  are  thus  computerized  and,  while  tne  ASIS  target  system 
is  not  tne  most  modern  of  data  case  systems,  it  is 
efficient,  effective  and  fast.  <rhen  tne  functional 
responsl bill ty  for  maintaining  targets  is  passed  asnore  to 
the  landing  force  TIO,  the  computer  system  is  replaced  by  an 
index  card  filing  system,  wnicn,  wnlie  effective,  is  neitner 
fast  nor  efficient  by  comparison.  Additionally,  the  index 
card  system  lends  itself  to  inaccuracies  and  omissions  in 
target  data,  particularly  when  tne  information  must  be 
maintained  in  a  timely  manner.  The  tactical  requirement  for 
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accurate  and  timely  target  Information  Is  no  less  critical 
or  Important  wfien  tae  landing  force  Is  on  tee  beacn,  yet  tne 
system  to  accompllsn  tnis  tasK  is  antiquated  and  cumbersome. 

The  staff  of  the  TIS  manually  transfers  the  target 
information  lata  contained  in  the  ASIS  data  base  to  5  cy  B 
inch  tareet  carls.  After  duplicating  the  entire  target  file, 
the  TIS  must  construct  a  cross  reference  file  to  list  tne 
target  by  grid  location  and  a  cross-index  file  to  Keep  tracK 
of  certain  types  of  targets.  In  addition  to  tne  target 
cards,  the  TIS  also  makes  up  lists  of  particular  categories 
of  targets  which  may  be  of  interest  or  value  to  members  of 
the  FSCC. 

The  TIS  obtains  < ntell itrence  information  from  landing 
force  and  supporting  arms  agencies,  converts  this  to  target 
Information  and  enters  the  information  into  the  target  card 
files.  The  information  is  made  available  to  the  supporting 
arms  representatives  in  the  ISCC  and,  based  on  the  TIO's 
recommendations,  a  decision  is  made  when  ana  now  to  attacK  a 
particular  tareet.  Results  or  attacKS  on  tareets,  front  line 
reports  and  intelligence  information  are  used  to  refine  tne 
tareet  list  and  delete  or  depriorltize  those  tareets  that 
present  a  diminished  threat  to  the  landing  force. 

Access  to  specific  information  from  the  tareet  list  (for 
example,  more  man  one  category  of  me  cross-index  files) 
requires  physically  searchine  throuen  each  list  and 
constructing  sub-lists  to  determine  tne  appropriate 
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timely  and 


Information.  Tne  constant  avaiiaollity  of 
accurate  tareet  information  is  reouired  for  tne  effective 
employment  of  supporting  arms  and  planning  of  fire  support. 
Tne  T15  plays  a  itey  role  in  providing  tnls  Information  and 
tne  constant  process  of  adding  to  tne  target  list,  selecting 
targets  for  attacic  and  deleting  targets  once  neutralized  is 
performed  by  tne  TIS  staff  using  tne  target  card  file. 

C.  INTEGRATED  FIRE  AND  AIR  SUPPORT  SISTB^ 

One  of  me  most  complex  asnects  of  modern  ampnlbious 
warfare  is  tne  control  and  coordination  of  supporting  arms 
oarticularly  in  tne  transition  of  responsibility  from  tne 
Navy  in  ampnibious  snips  to  tne  Marine  Corps  combat  units 
asnore.  The  grease  pencils,  map  boards  and  field  radios  tnat 
nave  served  Marines  so  wen  since  tne  days  of  Guadalcanal 
will,  in  the  future,  be  eclipsed  by  the  automated  system 
called  tne  Marine  Integrated  Fire  and  Air  Support  System 
(MIFASS). 

MIFASS  is  part  of  tne  Marine  Corps  integrated  command 
and  control  system  called  MTACCS  {Marine  Tactical  Command 
and  Control  Systems),  a  collection  of  eigni  major  systems 


which  will  give 

the 

Marines 

a 

capability  of  exercising 

real-time 

command 

and 

control 

of 

combat  forces  in  tne 

pos  t-l980 

time 

frame . 

MIFASS 

Is 

designed  to  perform  tne 

functions  of  tne  fire  support  coordination  center,  (FSCC^ 
tne  direct  air  support  center  (DASC)  and,  to  a  degree,  tne 


artillery  fire  direction  center  (FDC)  at  one  central 
location  called  tne  Fire  and  Air  Support  Center  (FASCK 

It  is  a  disiributed  processing  system  in  whi''h 
microcomputers  control  interactive  display  devices,  manage 
data  bases,  perform  computational  tasKs  and  drive  printers 
to  provide  nard-copy  records  of  messages  ana  operator 
decisions.  It  is  currently  in  full  scale  engineering 
development  wltn  an  initial  operational  capability  planned 
for  tne  1966-1987  time  frame.  MIFASS  addresses  tne 
requirement  for  target  information  by  providing  tne  TIO  witn 
a  digital  display  device  wnicn  will  nave  botn  a  grapnlcai 
representation  of  tne  target  on  a  battle  map  and  a  video 
screen  for  alpnanumeric  display  of  target  information. 

D.  NAiaRB  OP  THE  PROBLEM 

An  automated  solution  to  tne  target  information  function 
will  not  be  realized  until  tne  introduction  of  tne  MIFASS 
computers  into  tne  Fleet  Marine  Forces.  Until  sucn  time  as 
tne  system  is  delivered,  tne  target  information  function  of 
tne  FSCC  is  tied  to  tne  current  doctrine  and  tne  target  card 
filing  system. 

In  this  report,  an  interim  systems  solution  to  tne 
problem  of  automating  tne  target  information  function  of  tne 
FSCC  is  presented.  It  computerizes  those  basic  functions  of 
tne  TIS  in  a  simple,  Inexpensive  and  effective  manner.  It 
simplifies  tne  tasKS  of  the  TIS,  provides  a  mechanism  for 
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rapid  and  accurate  retrieval  of  target  information  ana  could 
Improve  the  operational  capability  of  the  FSCC. 

S.  NATffRB  OF  THE  SOLUTION 

Tne  amount  of  target  information  tnat  needs  to  be 
processed  is  sufficiently  small  that  a  microcomputer  is  tne 
most  suitable  piece  of  hardware  for  implementation.  Tne 
current  versions  of  microcomputers  are  very  versatile  witn 
efficient  operating  systems,  various  input/output  media 
Including  video  terminals,  inexpensive  and  relatively 
portable  secondary  storage  media  (floppy  disicettes  and 
cassettes),  niga  level  language  programming  capabilities  and 
even  scaled  down  versions  of  data  base  management  systems. 
Thus,  tne  tecnnology  in  nardware  as  well  as  software 
currently  exists  in  tne  commercial  maricetplace  and  it  is 
possible  that  a  practical  system  can  result  from  efficient 
and  careful  design  and  implementation. 

The  design  task  is  broken  down  into  three  distinct 
parts,  eacn  of  wnlcn  is  influenced  by  tne  overall  design 
characteristics  and  is  individually  addressed  in  separate 
Chapters . 

Tne  design  of  me  pnysicai  and  logical  data  base  is 
influenced  by  the  desire  to  nave  a  simple  yet  sufficiently 
informative  data  model,  a  rapid,  real-time  response  and  a 
restricted,  single  application  system.  The  system  design  is 
influenced  by  tne  microcomputer  environment  wnlcn  restricts 
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tr.s  user  botn  in  main  memory  space  and  trie  speed  of  access 
10  secondary  storaee  and  the  requirement  for  an  effe^'ilve 
interactive  system  for  a  non-sopnisticated  user. 

The  design  of  me  software  to  implement  bom  the  data 
oase  and  the  system  is  overwhelmingly  influenced  sy  tae 
requirement  that  the  system  support  real-time,  interactive 
processing  of  a  casual,  noc-prograrmer .  Termed  "^'arine 
proof"  in  the  vernacular,  it  reouires  a  sophisticated 
interface  employing  user  friendly  dialogue  tecnniques  to 
ensure  that  the  operation  is  simple  and  efficient.  For  this 
reason,  and  to  facilitate  system  portability,  a 
microcomputer  compatable  ni^h  level  programming  ian^ua^e  is 
employed  In  implementation. 

In  order  to  oetter  identify  the  user  environment  and  to 
Obtain  an  understanding  of  the  functions  of  target 
information,  me  next  cnapter  describes  tae  mission  and  the 
current  procedures  or  me  target  information  section.  It  is 
from  tnls  information  that  the  system  characteristics  were 
developed  and  the  design  based.  The  information  was  obtained 
from  Mavy  and  Marine  Corps  doctrinal  publications  as  well  as 
current  operating  procedures  of  a  Marine  Division  target 
Information  section.  Chapters  III  through  71  develop  in 
detail,  the  reasons  for  the  parameters  selected  and  the 
decisions  made  in  me  design  of  me  overall  system,  tae 
logical  and  physical  lata  base  and  me  applications 
software. 
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Caapter  VII  adiresses  tne  impiementation  of  tne  system 
and  further  implications  of  system  application  in  the  '^arlne 
Corps,  as  well  as  tactical  employment  and  interface  witn 
current  and  future  systems.  Conclusions  and  recommendations 
are  included  in  tne  last  chapter. 

The  source  code  llstinir,  which  has  been  developed  as  a 
result  of  inis  tnesls,  nas  been  published  as  a  Naval 
Post<?raduate  School  technical  report  entitled  A  Prototype 
Program  for  Target  Information  (NPS5iJ-8l-ed^'?) .  A  data 
dictionary  and  an  example  of  tne  system  Interface  are 
included  in  tne  appendices.  A  bibiiograpny  of  applicable 
references  and  a  list  of  abbreviations  used  are  also 
included . 


II .  TARGET  iNFORyiATION  PRQCSDUHgS  AND  SMFLOYyiSNT 

A.  GENERAL 

A  precise  unaerstandlng  of  tfle  duties  of  tne  target 
information  officer  and  procedures  used  oy  tne  target 
information  section  is  required  Before  detailed  requirements 
for  an  automated  target  information  system  can  oe  stated. 
Tnis  cnapter  is  devoted  to  tnat  purpose.  It  discusses  and 
examines  in  detail  tne  doctrinal  duties  and  functions  of  tne 
target  information  officer  and  tne  current  procedures  for 
executing  tnese  functions. 

The  tareet  information  officer  is  a  member  of  the  fire 
support  coordination  center  (ESCC).  He  and  nis  staff  provide 
target  information  to  the  fire  support  coordinator  so  that 
effective  employment  of  supporting  arms  is  driven  by  timely 
and  accurate  target  intelligence.  He  works  directly  witn  tne 
artillery  representatives t  me  air  officers  and  tne  naval 
gunfire  support  officers  in  aiseminating  appropriate  target 
information  and  obtaining  surveillance  information.  He 
assigns  battle  damage  assessments  for  attacked  targets  and 
further  refines  the  target  list. 

His  relatlonsnip  with  boin  tne  ampniblous  task  force 
target  intelligence  officer  and  the  landing  force  target 
Intelligence  officer  is  extremely  important  since  it  is  from 
these  sources  tnat  ne  obtains  the  target  Inteiiigence  which 
generates  tne  target  Information. 
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B.  DUTIES  OF  THE  TARGET  INFORMATION  OFFICER 


Tfie  TIO  is  a  Marine  Corps  officer  wno  performs  nis 
duties  under  tne  staff  cognizance  of  tne  fire  support 
coordinator  (FSC)  and  trorics  closely  witn  tne  laniin;?  force 
ooerations  and  intelligence  sections.  Tfce  primary  doctrinal 
puolicatlon  for  tne  Marine  Corps  is  Fleet  Marine  Forre 
Manual  (FMFM)  7-1  (Fire  Support  Coordination'  »nicK  outlines 
nis  duties  as  follows: 

1.  Keeping  tne  FSC  and  tne  otner  fire  support 
representatives  in  tne  FSCC  informed  of  tne  status  of 
targets . 

2.  Ensuring  tnat  pertinent  tareet  intelligence  is  posted 
on  tne  FSCC  target  and/or  situation  maps. 

3.  Preparing  and  maintaining  target  file  carls. 

4.  Entering  target  attacK  evaluations  and  surveillances 
on  tne  target  cards. 

5.  Supervlsin?  tiie  operation  of  tne  target  information 
section  (TIS)  of  tne  FSCC. 

5.  Preparing  tne  landing  force  list  of  targets  or  tne 
Marine  air-ground  tas!c  force  (MACTF)  target  list  for 
promulgation  by  tne  operations  officer.  Tne  FSCC  win 
provide  targets,  to  include  tnelr  classification  and 
priorities,  wnlcn  are  to  be  included  in  tne  target  list, 
target  bulletins  and/or  lists  of  targets. 

7.  Preparing  and  releasing  target  bulletins  when  control 
of  tne  target  list  nas  been  passed  to  tne  commander 
landing  force  or  wnen  tne  MAGTF  is  engaged  in  lanri 
warfare . 

B.  Keeping  tne  target  Intelligence  officer  advised  of 
target  information  available  tnrougn  supporting  arms 
sources. 


C.  FUNCTIONS  Of  TKf  TAP.5ET  iNfORr^ATION  SECTION 


The  functions 

of  t  r.e 

Tib  are 

oriented  to 

tne 

requirements  of  tne 

supporting 

a  rm  5  (air. 

naval  gunfire 

and 

artillery)  in  tne  preparation  of  fire  support  plans  and  tne 
conuand  requirements  for  target  information.  Tne  TIS  uses 
all  of  tne  avaiiaoie  intelli^etice  garnered  by  tne  aeen^'ies 
of  tne  ampnibious  tasK  force  and  tne  landing  force.  Tnese 
agencies  include  landing  force  and  ampnibious  tasic  force 
target  intelligence  sections  and  intelligence  agencies  of 
tne  supporting  arms. 

Tne  TIS  is  responsible  for  recording  ail  target 
information,  analyzing  tnis  target  information,  maintaining 
records  and  maKlng  recommendations  of  targets  v.nicft  are 
appropriate  for  attacit.  7-i  lists  tne  following 
functions  of  tJie  TIS: 

1.  Maintaining  required  target  ana  situation  maps. 

i.  Maintaining  target  cards  and  target  files,  including 
cross-indexed  files  of  target  information. 

3.  Consolidating,  evaluating  and  displaying  target 
Information. 

4.  Recommending  classification  and  attaci  priorities  to 
tne  fSC. 

5.  Collecting  from  all  agencies  and  sour''es,  any 
information  pertaining  to  tne  results  of  attacic  on 
targets  by  tne  supporting  arms. 

6.  Consolidating  and  evaluating  results  of  attacks  by 
tne  individual  supporting  arms  and  tne  metnods  of 
attacic,  and  recommending  additional  measures  taat  appear 
necessary  from  tne  overall  results  and  analyses. 
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7.  Coorctiaaiini?  on  aii  matters  witn  tne  landing  force 
tarf^et  intelligence  officer  and  tne  artillery  unit 
intelli?enc9  officer  for  target  and  counterfire 
information  and  correlation  of  records  and  files. 

B.  'Maintaining  current  counterfire  target  lists  to 
include  counter-mortar,  counter-battery  and  3KAC 
(suppression  of  enemy  air  defense)  lists  and  providing 
tais  information  to  tne  supporting  arms  representatives 
as  well  as  ensuring  dissemination  to  tne  landing  force 
as  a  waole. 

y.  Preparine  and  lisseirinatins  target  bulletins 
(TaR3>IL's)  after  control  of  tne  target  list  nas  been 
passed  asnore. 

12.  Maintaining  a  nuclear  and  cnemicai  target  foiaer  to 
assist  in  tae  selection,  evaluation  and  planning  of 
attacK  by  supporting  arms  utilizing  nuclear  and  caemi^al 
munitions. 

Tne  composition  and  organization  of  tae  TIS  varies  wita 
tne  FSCC  level  out  typically  at  tne  landing  force  level  it 
consists  of  one  officer  (TIO)  and  from  one  to  taree  enlisted 
personnel.  Personnel  are  usually  trained  in  target 
intelligence,  supporting  arms  capabilities  and  limitations, 
organization,  fire  support  coordination  principles  and 
communications . 

Wniie  tne  functions  and  duties  of  target  information 
personnel  are  determined  by  tae  doctrinal  publications,  tne 
actual  procedures  to  accomplisn  tnese  functions  will  differ 
sllgntly  from  one  organization  to  anotaer,  nowever  tnese 
variations  are  minor. 


D.  TAP.GfiT  INFORMATION  RECORL'S  AND  FILES 


Tile  records  and  files  of  tareet  information  consist 
pri-narily  of  situation  maps,  target  file  carls,  target  lists 
and  cross-indexing  files  at  tne  landing  force  level.  Tney 
are  tne  tools  used  to  catalogue,  analyze  and  disseminate 
target  information. 

The  tareet  map  provides  a  visual  referen^^e  of  targets 
appropriate  for  attactt  by  supporting  arms.  Tne  friendly 
situation  map  contains  all  information  pertinent  to 
supporting  arms  operations  and  typically  includes 
objectives,  front  lines,  fire  support  control  measures,  unit 
boundaries  and  unit  locations. 

Tne  bulic  of  tne  record  Keeping  involves  tne  target  file 

card.  The  file  of  b  by  fc  inch  cards  contains  a  separate 

target  card  for  each  Known  or  suspected  target  both  by 

tareet  number  and  by  erid  coordinates.  Fleure  1  is  an 

example  of  a  target  card.  Information  appearing  on  tne 

target  card  includes  the  following: 

target  symbol  (conventional  map  symbol) 

target  number 

target  classification 

attacK  priority 

target  location  (grid  coordinates) 
target  elevation  in  meters 
map  reference 
target  description 

assignment  of  supporting  arms  attacK  means 
source  and  date  of  target  information 
photograph  number  and  grid  location 
remarKs  of  additional  significance 
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Figure  1. 

Sxarpie  of  a  Tart:?:  Cari. 

• 

The  targei  cross-index  file  consists  of  one  card  or  list 
for  each  type  of  tar<ret  (e.g.,  counter-Dattery,  arncr,  Si’AD, 
fortification,  etc.).  Each  card  or  list  typically  includes 
only  the  tareet  numoer  of  each  target,  it's  priority,  the 
recomiiended  inetnol  of  attacic  ana  tne  final  disposition  of 
the  tareet. 


In  a 

typical 

ampni tious 

ope 

ration , 

tne  landing  force 

usually 

operates  with  a 

maximum  of 

approximately  200-.500 

targets . 

iVith  a 

separate  target 

card 

for  each  target  by 

tareet 

num  oer 

as  well 

as 

Dy  sri 

1  coordinate  and  a 

cross-index  card  for  tne  IJ?  to  15  target  types,  tne  target 
file  can  easily  exceed  500  caras.  An  example  of  a  Marine 
division  target  card  file  organization  is  illustrated  in 
figure  2. 


ACTIVE  TARGETS  INACTIVE  TARGETS 


Figure  2.  Target  Card  File  Organization. 
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THE  TARSET 


LIST 


• 

A  se-Tiantlc  distinction  must  ne  made  between  tne  ’’tar^;et 
list”  and  tfie  "list  of  targets”.  The  "target  list"  is  a 
collection  of  targets  wnlcn  is  maintained  ana  promulgated  by 
tfte  senior  echelon  of  command.  There  is  only  one  "tareet 
list".  It  contains  targets  wnlcn  are  pertinent  to  tne 
landing  force  as  a  wnoie  and  whicn  are  to  be  taKen  under 
attactc  by  supporting  arms.  A  "list  of  targets"  is  maintained 
at  any  echelon  of  command  and  includes  those  confirmed, 
suspected  or  possible  targets  for  information  ana  planning 

purposes  as  well  as  for  possible  attacK  by  supporting  arms. 


The  "target  list"  is  a 

subset  of 

the 

"list  of 

targets" . 

Subordinate  units 

use  the 

target  list 

as  their  basic 

source  of  targets  and 

also  include 

targets 

that  have  a 

significant  but  specific  or  "short-life”  value  to  their 
operations  in  tnelr  unit  list  of  targets.  ^s  an 
Illustration,  a  battalion  would  only  include  those  targets 
from  tne  landing  force  target  list  wnlcn  were  located  in  or 
adjacent  to  their  zone  of  action. 

Targets  can  be  further  described  as  active  or  inactive. 
An  active  target  is  one  which  is  on  tne  target  list  or  list 
of  targets  and  presents  a  oonaflde  current  or  future  enemy 
capability  to  interfere  with  operations.  An  inactive  target 
is  one  wnlcn  nas  been  overrun  by  friendly  forces  or 
destroyed  by  supporting  arms  or  has  shown  no  activity  for  7"d 
nours  and  no  damage  assessment  nas  been  made,  although  these 
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latter  targets  are  inactivated  wltn  caution.  Tne  Inactive 


targets  are  placed  la  a  deadflie  and  reactivated  If 
necessary.  Figure  3  depicts  tne  target  list  terminology. 


ACTIVE  TARGETS  INACTIVE  TARGETS 


Figure  3.  Target  List  Terminology. 

P.  TARGET  CLASSIFICATION 

Targets  are  classified  oy  tne  effect  wnlcn  tneir 
existence  or  elimination  may  nave  on  tne  ampnlblous  tasic 
force  and  by  restrictions  Imposed  by  the  commander  on  tne 
attacfc  of  certain  targets. 

The  primary  doctrinal  publication  for  ampnlbious 
warfare,  NitfP  22-2  (Supporting  Arms  in  Amphibious  Operations) 
list  tne  following  target  classifications: 

Class  A. ..Targets  that  threaten  snips,  aircraft, 
minesweeping  and  underwater  demolitions 
operations . 

Class  B,. .Targets  tnat  threaten  assault  forces  In  the 
snlp-to-snore  movement  and  assault  of  the 
beach . 

Class  C.. .Targets  tnat  threaten  or  oppose  landing  force 
operations  afteriandlng  or  affect  tne  ability 
of  tne  enemy  to  continue  resistance. 
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Class  D. ..Targets  tnat  will  not  De  firea  on  prior  to 
D-Day . 

Class  E.,.Tareet5  tnat  must  not  ne  destroyed  (unless 
specific  orders  for  sucn  destruction  are 

issued  by  tiie  ampnlblous  tasK  force  or  landing 
force  comnander)  eltner  because  of  probable 
future  use  by  our  own  forces  or  for 

humanitarian  reasons.  These  Installations  may 
be  neutralized,  harassed  or  Interdicted  if 
prior  approval  is  obtained  from  the  commander 
Imposlnif  the  restrictions. 

(J.  TAR&ET  PRIORITY 

The  target  Information  officer,  in  coordination  wltn  tae 
target  inieilleence  officer,  the  fire  support  coordinator 
and  the  supporting  arms  representatives  reviews  and 
recommends  the  assignment  of  attacK  priority.  The  target 
priority  Is  established  to  determine  the  sequence  of  attacic 
and/or  the  effort  to  be  allocated  to  a  eiven  target.  The  TIO 
establishes  tne  priority  based  on  the  target's  effect  on  the 
accomplishment  of  the  landln<r  force  mission  and  its  relative 
Importance  as  compared  to  otner  targets. 

7-1  lists  the  following  tareet  priorities: 

Priority  I . Targets  capable  of  preventing  the 

execution  of  the  plan  of  action  by  the 
landing  force  and  its  elements. 

Priority  II ... .Targets  capable  of  immediate  serious 
Interference  with  the  plan  of  action  of  the 
landing  force  and  its  elements. 

Priority  III. .  .Targets  capable  of  ultimate  serious 
Interference  wltn  tne  plan  of  action  of  tne 
landing  force  and  Its  elements. 

Priority  17. .. .Targets  capable  of  limited  interference 
with  tne  plan  of  action  of  tne  landing 
force  and  Its  elements. 
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H.  THE  TARSET  BULLETIN 

In  oraer  to  maintain  up-to-date  tar^rei  information 
records,  it  is  essential  ttiat  reports  of  tne  discovery  of 
new  targets  and  tfte  analysis  of  supporting  arms  attarics  on 
existing;  targets  be  reported  to  tne  appropriate  units.  Tne 
TIO  evaluates  and  consolidates  reports  of  target  information 
and  supporting  arms  battle  damage  assessment  fEDA)  and 
prepares  a  target  bulletin  (TARBUL).  Upon  approval,  it  is 
released  to  interested  commanders  of  nigner,  lower  and 
adjacent  elements  of  tne  ampnibious  tass  force. 

Tne  TARBUL  is  normally  transmitted  over  existing 
teletype  or  radio  circuits  and  typically  adds  new  targets  to 
tne  target  list  (giving  me  target  number,  location, 
elevation,  priority,  classification  and  description),  gives 
damage  assessment  to  existing  targets  wnlcn  nave  been 
attacited  by  supporting  arms,  canceils  targets  from  tne 
target  list  (relegating  tnem  to  tne  deadfile)  and 
reactivates  previously  cancelled  targets.  TARBUL's  are 
serialized  and  issued  on  an  as-needed  basis. 

I.  OPERATIONS  OF  THE  TARGET  INFORMATION  SECTION 

While  tne  target  information  section  is  neavliy  involved 
in  the  early  phases  of  the  operation,  tne  most  important 
witn  respect  to  tnls  thesis  occurs  during  tne  preparation  of 
the  objective,  shlp-to-shore  movement  and  operations  ashore. 
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The  target  list  Is  Inltaily  maintained  by  the  SACC 
tareet  Intellleence  officer.  Tne  tareet  information  is 
stored  in  a  data  base  of  tne  ASIS  system  and  a  navy  computer 
operator  wortln^  in  the  SACC  operational  spaces  uses  tne 
ODEST  data  base  query  langua<?e  to  access  targets  and  target 
information  from  tne  data  base.  Requests  for  a  target 
listing  and  for  special  purpose  reports  must  oe  composed  in 
tne  query  lan<ruaee  each  time.  Response  to  the  query  is 
displayed  on  a  video  display  unit  in  tne  SACC.  Tne  report 
printouts  are  available  from  a  printer  located  in  the  main 
computer  spaces. 

During  this  period,  tne  TIO  is  monitoring  and 
duplicating  tne  target  list  with  tne  target  card  files.  It 
typically  Is  an  opportunity  for  tne  TIS  staff  to  become  very 
familiar  witn  tne  target  card  file  procedures,  aitnougn  it 
requires  almost  a  complete  duplication  of  effort  between  me 
TIC  and  tne  TIS. 

When  tne  TIS  goes  ashore  wltn  tne  landing  force  fSCC, 
they  obtain  computer  printed  copies  of  the  latest  tareet 
list  as  a  backup  to  tnelr  card  file.  Changes  to  tne  target 
list  durlne  the  phasine  of  tne  TIS  asnore  are  covered  by  a 
TARBUL  issued  by  tne  commander  ampnlbious  tasJc  force. 

Operations  ashore  are  cnaracterized  by  constant 
refinement  of  tne  target  list,  adding  newly  acquired  targets 
and  tne  employment  of  supporting  arms  on  existing  targets. 
Wnen  target  Information  is  received,  tne  target  is  plotted 
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on  the  target  TJap,  a  classification  assi?nea,  a  target  card 
prepared  and  all  available  information  evaluated.  A  priority 
of  attact  is  assigned  and  a  recommendation  regarding  attacK 
by  supportlne  arms  is  made.  The  tarset  carl  is  then  added  to 
tne  target  number  file,  tne  grid  location  file  and  tne 
cross-index  file  if  necessary. 

As  fire  support  missions  are  executed,  tne  TIS  attempts 
to  expedite  tne  surveillance  reports  from  the  available  fire 
support  sources.  A  damage  assessment  is  male  based  on  tne 
reported  surveillance.  The  Information  is  added  to  tne  fcacK 
of  the  target  can  and  the  target  is  updated  as  required. 
The  primary  sources  of  this  information  are  artillery 
forward  observers,  naval  gunfire  spotters,  forward  air 
controllers  and  liaison  officers. 

New  targets  are  reported  to  the  landing  force  TIS  from 
the  target  Information  sections  of  subordinate  units  who 
nave  uncovered  targets  of  sufficient  importance  to  be 
recommended  for  Inclusion  on  the  target  list.  Targets  are 
also  receivel  from  tne  target  Intelligence  officer,  tne 
artillery  tareet  acquisition  battery  and  acoustic  and 
seismic  sensors.  Based  on  tne  accuracy  of  mis  information 
(confirmed,  probable,  possible  or  unknown),  a  determination 
is  made  wnetner  to  add  tne  target  to  tne  target  list,  tne 
list  of  targets  or  the  Inactive  file. 
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J.  OPERATIONAL  CHARACTERISTICS 


Th?  operations  of  tne  TIS  focus  on  two  major  functions* 
tne  maintenance  of  tne  target  card  file  and  tne  erapnlcai 
representation  of  tne  target  Information  on  tne  target  map. 
Tne  former  function  appears  to  lend  Itself  to  an  effective 
automated  solution.  Tne  following  items  are  tne  significant 
recurring  requirements  for  maintenance  of  tne  target  card 
file: 

adding  a  target  to  tne  file 
deleting  a  target  from  tne  file 
cnanglne  information  about  a  tareet  in  tne  file 
cnanglng  tne  status  of  a  target  (active-inactive) 
updating  tne  cross-index  file 

Tne  products  of  tnis  maintenance  are  used  by  tne  TIO  and 

tne  staff  of  tne  FSCC  for  effective  fire  support 

coordination  and  delivery  of  supporting  arms.  An  analysis  of 

tnese  products  indicate  tnat  tne  target  card  file  provides 

tne  following  specific  capabilities: 

provides  all  target  information  for  a  specific  target 

differentiates  between  active  and  Inactive  tar?eis 

sorts  or  catalogues  targets  oy  various  parameters  (wnicn 
Include  target  no.,  coordlrates,  classification, 
priority,  target  type,  supportine  arm  asslened  and 
target  accuracy) 

provides  information  upon  wnicn  to  base  a  TARBUL 
provides  Information  for  production  of  tne  target  list 

3t> 


Any  automated  solution  wnicn  will  be  of  value  to  me  TTO 
must  be  able  to  perform  tne  requirements  for  mainterance  of 
tne  tari;et  file  quiciiy  and  efficiently.  It  must  provide  tne 
required  end  products  (TARJJUI,  target  lists,  specific 
information  about  a  particular  target,  etc.)  as  well  as  tne 
capability  of  providing  specific  target  information  In  a 
manner  and  format  wnicn  can  best  he  utilized  in  tne  FSCC. 

Tne  solution  involves  tne  manipulation  and  management  of 
the  Information  contained  on  each  target  card  In  such  a  way 
that  the  speed,  efficiency  and  effectiveness  of  the  TIO  is 
enhanced.  This  must  be  done  In  a  simple,  easy  and 
uncomplicated  manner  and  must  produce  timely  and  accurate 
Information. 

K.  SUMMARI 

The  organization  examined  in  this  chapter  is  for  the 
landing  force  target  Information  section  (TIS)  (typically  a 
Marine  division  or  a  Marine  amphibious  brigade)  wnicn 
constitutes  the  most  Important  and  most  heavily  staffed 
section.  The  TIS  exists  at  regimental  and  battalion  level  as 
well,  but  with  less  formality.  The  card  file  is  not  as 
extensive  (due  to  the  fewer  number  of  targets  In  tne  zone  of 
action  of  a  smaller  unit)  and  the  target  personnel  usually 
perform  tneir  functions  as  an  additional  ratner  tnan  a 
primary  duty.  Tne  automated  solution,  however,  is  equally 
useful  for  subordinate  units  of  tne  landing  force  In 
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assisting  taem  in  tne  effective  ana  timely  managerent  cf 
ta^i^et  inforTaiion  so  tnat  tney  may  effectively  employ  ineir 
supporting  arms  on  tne  most  important  targets. 

This  Chapter  has  provllea  a  review  of  tne  duties  and 
functions  of  tne  target  information  section,  tne  tools  and 
doctrinal  procedures  of  target  Information  ana  the 
tecnnlques  of  operation,  idditlonally ,  tne  characteristics 
of  tfte  tareet  Information  function  which  can  be  automated 
nave  been  lientified  and  analyzed.  Tne  followine  chapter 
uses  this  analysis  to  develop  a  conceptual  framewortt  for  tne 
design  of  tne  target  information  system. 
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Ill  .  SYSTEM  DESIGN  CONS  IDiilRAT  IONS 

A.  PRIMAP.r  CONSIDERATIONS 
1 .  SacggroutiA 

Having  defined  tne  current  procedures  for  tde  target 
Information  function,  tne  tasic  now  remains  to  provide  a 
satisfactory  system  design  for  an  automated  solution.  Tne 
design  Is  Influenced  by  two  Important  considerations.  Tne 
nature  of  tne  lata  case  is  botn  pnysicaily  small  in  size  and 
functionally  restrictive  In  wnat  Information  is  required 
from  It.  This,  comolned  with  a  requirement  for  a  relatively 
ilgntweignt,  portable  and  versatile  computer,  manes  tne 
selection  of  a  microcomputer  an  obvious  and  logical  cnoice 
for  nardware.  Tnls  confines  tne  solution,  nowever,  to  tne 
microcomputer  environment  wnicn,  wnile  it  nas  many  desirable 
features,  imposes  a  number  of  major  restrictions  on  tne 
design. 

Tne  second  major  influence  on  tne  design  is  tne  impact 
of  numan  engineering  on  tne  user  interface.  Tne  user  is  a 
Marine  in  tne  target  information  section  of  tne  FSCC  and  tne 
functions  ne  performs  are  a  snown  entity.  Tne  system  must 
conform  botn  to  nis  level  of  training  and  computer 
sopni stl catl on  and  to  tne  functions  and  tasics  ne  performs. 
Tnis  requires  an  Interface  wnicn  is  user  friendly,  extremely 
easy  to  operate,  sufficiently  sopnistlcated  to  allow  tne 
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perform  toe  required  functions  effectively  and 
wittiout  error,  and  capable  of  operating  in  a  real-time, 
interactive  mode. 

Thus,  ibe  solution  is  confined  by  two  separate 
environments:  tne  microcomputer  environment  and  tne  one 
defined  by  tne  friendly,  sopnistica ted  user  interface.  Tney 
Jointly  determine  tne  data  structures,  tne  control 
structures,  memory  allocation.  Interactive  complexity  and 
tae  system  modular  design.  Tne  system  must  be  designed  to 
operate  effectively  wltnin  tne  restrictions  Imposed  by  tne 
microcomputer  and  tne  parameters  required  by  tne  user 
interface,  in  abstraction  of  inese  environments  is  depicted 
in  flcure  4  below. 


Figure  4.  System  Deslen  Environment. 


2.  lasts 

A  tey  tast  in  tae  system  design  is  tne  definition  of 
tne  usa^e  factor.  Tnis  is  tne  description  of  tne  system's 
processing  requirement,  l.e.,  now  tne  lata  is  utilized  by 
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the  systsTi.  This  leads  to  a  top-down  design  irethodology  and 
tnree  l-nportant  tasKs  wnlcn  will  determine  tne  design  oi  tne 
data  Case  as  well  as  the  applications  program.  These  tastes 
are: 

1.  To  Identify  ail  processing  functions  ana  suoalviae 
these  functions  into  modules  (processes^. 

2.  To  determine  ail  of  tne  data  that  eacn  process  uses  to 
perform  its  designated  function. 

3.  To  adequately  describe  tne  system  retrieval 
requirements . 

B.  THE  USER  INTERFACE 

While  Chapter  VI  will  address  in  detail  tne  numan 
engineering  aspects  of  the  user  interface,  it  is  important 
to  recognize  at  this  point  in  tne  development  of  tne  system 
that  the  user  is  classified  as  a  parametric  user.  Simply 
defined,  tne  parametric  user  is  one  wnose  system  input  is  in 
the  form  of  parameters  only.  He  is  not  a  programmer  although 
he  may  nave  programs  available  that  he  can  use.  He  is 
transaction  oriented,  putting  information  into  the  system 
and  retrieving  it  from  the  system,  generally  requiring  a 
Short  response  time.  The  parametric  user  requires  current 
and  timely  data  and  rapid  ana  easy  recovery  from  errors. 

In  addition  to  designing  the  system  to  perform  the  tasics 
and  functions  of  target  information,  it  must  be  engineered 
for  the  parametric  user  in  order  for  it  to  be  used 
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effectively  anl  with  a  deeree  of  confidence  because  of  its 
predictable  benavlor. 

In  tne  design  of  an  interactive  system,  a  very  important 
consideration  is  tne  appearance  of  tne  system  to  tne  user. 
Use  of  tne  tecnni^ue  cf  interaction  by  anticipation,  tnat 
is,  anticipating  tne  desires  of  tne  user  ana  presenting  nim 
with  a  corresponding  list  of  options,  allows  tne  user  to 
simplify  nis  input  by  selectine  ratner  tnan  specifyin?  tne 
data.  Tne  employment  of  menu  selection  tecnni^ues  and 
computer  initiated  dialogue,  important  applications  of 
interaction  by  anticipation,  will  be  used  to  provide  tne 
friendly  man-macnine  interface. 

C.  US3R  DSSISN  CRITERIA 

A  particularly  important  aspect  of  tne  design  is  tne 
nature  of  tne  constraints  on  tne  cognitive  processes  of  tne 
user.  One  constraint  is  tne  amount  of  information  tnat  a 
person  can  consider  at  one  time  and  tne  lenetn  of  time  tnat 
tne  information  can  be  retained  in  snort  term  memory.  Hence, 
tne  Information  available  from  tne  system  snouid  be  simple 
enougn  to  be  qulciiiy  and  easily  assimilated. 

The  system  snouid  also  be  fast  enougn  so  tnat  tne  user 
is  not  distracted  by  tne  loss  of  information  in  nis  snort 
term  memory  due  to  a  slow  response  time.  Tne  system  snouid 
be  able  to  reinforce  user  memory  wnenever  required.  Tnls 
implies  a  user  initiated  request  for  neip  to  which  tne 
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system  must  reply  witn  tna  appropriate  information.  An 
important  aspect  in  lesigning  a  nei?  function  is  unifor-r’iiy 
Of  the  command  as  «fell  as  the  expected  reply. 

A  second  consideration  wnicn  is  important  in  tne  design 
of  interactive  systems  Is  the  experience  level  of  the  user. 
The  system  snouli  oe  aole  to  cater  to  tne  novice  user  and 
effectively  direct  nis  input  to  perform  the  required  tasKS  . 
It  is  also  important  for  the  system  not  to  ignore  tne 
experienced  user.  The  interface  should  be  able  to  adapt  to 
the  needs  and  characteristics  of  its  users  based  on  tne 
user's  experience. 

The  interface  snouli  also  be  robust  in  nature.  It  should 
respond  in  an  effective  and  unambiguous  manner  to  any  input 
and  allow  the  user  to  recover  from  simple  errors.  It  should 
discourage  illegal  input  and  guile  tne  user  to  tne  proper 
inputs  required.  It  should  provide  closure  to  the  user, 
i.e.,  a  logical  completion  to  a  specific  action  within  an 
expected  period  of  time.  It  should  limit  the  user  input  to 
the  necessary  data  and  instructions  sufficient  to  perform 
the  required  tasics. 

This  is  test  accomplished  for  me  parametric  user  cy 
interaction  by  anticipation  and  a  restricted  and  unambiguous 
flow  of  man-macnine  communications.  Thus,  communications 
from  the  user  to  the  computer  is  by  discrete  selection  of 
semantically  meaningful  options,  and  from  tne  computer  to 
tne  user  by  tne  presentation  of  information  contained  in  tne 
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•nenu  selection  or  llaicgue  frames.  Tnis  will  allow  for  rapid 
and  easy  operations  for  tne  user  and  a  unity  of  design  for 
tee  implementor. 

D.  THE  MICROCOMPUTER  ENVIRONMENT 

Microcomputers  Impose  a  stringent  set  of  restrictions  on 
tne  resources  avallaoie  wnea  Impienentlng  or  executing  a 
program.  Tnese  restrictions  include  tne  small  size  of  main 
memory,  tne  iengtny  access  time  and  small  capacity  of 
secondary  storage  and  tne  low  processing  rate. 

Typically,  microcomputers  are  constructed  witn  32  to  64K 
ftytes  of  main  memory.  Vnen  consideration  is  made  for  tne 
operating  system,  tne  applications  proeram  and  tne  data 
case,  it  becomes  oovlous  tnat  tney  cannot  ail  exist  in  main 
memory  at  tne  same  time  and  tne  partitioning  of  memory  and 
tne  arrangement  of  secondary  storage  will  ce  a  Key 
consideration  In  tne  system  design.  Putting  ail  tne  data 
into  main  memory  Is  not  feasible  because  of  Its  size,  yet 
putting  ail  tae  data  in  secondary  storage  results  In 
unacceptable  response  time. 

System  response  time  is  important  to  tne  user.  Tnus. 
tnose  operations  to  wnlcn  ae  expects  a  quicK  answer  must  be 
performed  quietly  wltn  minimal  access  time.  For  otner 
operations  wnica  are  logically  time  consuming  to  tae  user 
(for  example,  input  of  a  new  target  Into  tne  target  list', 
closure  will  nave  to  be  delayed  (wita  a  computer  advisory 


xessa^e)  wniie  tne  inf orTatioi  is  processed.  Tne  routines  of 


tr.e  applications  prograrr  Tust  he  iesigr.ei  to  cptioiize  me 
accesses  to  secondary  storage,  wnlcn  is  tne  coitieneci  in 
mlcrocoTiputer  systems. 

E.  FIVJCTIONS  OF  TKE  SYSTEM 

From  an  analysis  of  tr.,e  information  provided  Cy  tne 
tareet  card  file  and  tne  functions  and  duties  of  tne  target 
information  section,  a  numner  of  major  functions  of  tne 
system  nave  been  identified.  From  these  functions,  system 
output  nas  been  identified,  totn  in  tne  form  of  display  on  a 
video  terminal  and  printed  nard  copy.  Tnese  functions  and 
outputs  determine  tne  design  of  tne  data  case,  tne 
applications  program  and  tne  overall  system. 

1 .  Primary  Functions 

Tne  primary  functions  of  tne  system  involve  tne 

manipulation  and  input  of  target  Information  into  tne  proper 

storage  formats.  Tnese  functions  include: 

Add  a  target  to  tne  file 
Delete  a  target  from  tne  file 
Cnan^e  information  about  a  tareet 
Cnange  target  status  (actl ve/lnactlve ^ 

Copy  data  base  to  a  bacicup  file 
Initialize  tne  tareet  file  lata  base 
Display  certain  target  information 
Print  certain  target  information 

Tnese  last  two  functions  could  become  very  extensive 
operations  if  desired.  However,  a  carefully  restrictive 
design  of  tne  lata  base  model  and  a  desire  to  limit  tne 
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semantic  options  of  ine  parametric  user  to  certain, 
leflnel  operatioms,  ftas  reduced  tnetr  to  maaa^aoie  yet  fuiiy 
appllcaCle  functions. 

2.  Display  Options 

Tne  CRT  (catnode  ray  tv.ne)  device  «iii  te  tne 
primary  user  interface  mecnanlsm.  'lost  of  tne  information 
input  and  extracted  from  tne  system  will  ce  performed  via 
tne  CRT.  Tne  interactive  queries  to  tne  data  case  will 
result  In  tne  folio«inflr  display  options: 

Display  a  complete  target  card 
Display  a  list  of  all  tne  active  targets 
Display  a  list  of  all  tne  Inactive  targets 
Display  tne  target  list 

Display  tne  Information  for  tne  next  TARRUL 
Display  a  list  of  targets  by  specific  parameterfs) 

Display  parameter  status  for  tne  active  targets 

The  parameters  indicated  above  are  selected  cateeories 
of  target  information  obtained  from  tne  target  card  wnicn 
are  tne  typical  parameters  for  special  listins’s  and  tne 
cross-index  flies.  It  represents  a  selection  of  tnose  items 
of  Information  wnicn  can  be  most  effectively  utilized  by  tne 
?SC  and  tne  supporting  arms  representatives  in  tne  FSCC. 
Tnese  parameters  Include: 


Target  Priority 
Target  Classification 
Target  Nuncer 
Target  Status 
Target  Type 

Supporting  Arm  Assigned 
Attacicel  Target 
Target  Information  Accuracy 
5rld  Coordinates 

i.  Print  Options 

Earl  copy  of  tne  target  information  is  a  definite 
requirement  for  operations  at  any  level  i'SCC.  Tne  system 
rfill  have  tne  capability  to  print  the  target  list  and  tne 
list  of  targets.  The  production  of  a  TARBUL  based  on  tne 
transactions  with  the  lata  base  sin-'e  tne  last  published 
TARBUL  will  provide  a  significant  neip  to  tne  TIO. 

The  tareet  llstlnes  by  specific  parameter  (for  example, 
a  list  of  ail  active  targets,  class  C,  priority  II,  of 
target  type  "SEAC"  assigned  to  artillery)  is  a  requirement 
tnat  will  be  applicable  to  all  members  of  tne  i'SCC.  Tee 
system  will  also  nave  the  capability  to  print  a  "opy  of  tne 
target  card  for  dissemination  to  otner  asencies  as  well  as 
to  provide  a  manual  bacitup  in  case  of  power  or  computer 
failure. 

F.  SUrrART 

This  chapter  alone  with  tne  preceedine  chapter  nas 
defined  tne  doctrinal  functions  of  target  information, 
determined  the  environment  for  the  automated  solution  of 
tnese  functions  and  presented  tne  system  requirements  for 
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this  solution.  These  chapters  form  a  necessary  foundation 
for  the  suosequent  chapters  wnich  address  tne  specific 
details  of  tne  system  and  tne  data  nase  desi,tn.  Tne  next 
Chapter  addresses  the  actual  system  design  and  includes  me 
Hardware  and  software  selection  and  a  top-down,  modular 
anproach.  It  contains  important  decisions  concerning  me 
data  base  wnlcn  are  developed  in  greater  detail  in  cnapter 
7. 
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IV 


SYSTEM  DESISN 


A.  CONCEPTUAL  SYSTEM  DESIGN 

1.  Generality  of  Approacft 

In  rating  a  top-down  classic  approacn  to  tne  desien 
or  the  tareei  information  system,  tne  initial  design  does 
not  consider  tne  restrictions  imposed  oy  tne  operating 
environment.  Tnis  is  done  for  two  reasons.  First,  tne 
conceptual  design  presents  a  simple,  traditional,  straigni 
forward  solution  wnlcn  can,  in  concept,  ce  readily 
Implemented.  Second,  it  provides  tne  basis  upon  wnicn 
modification  and  adjustment  may  be  performed  to  fit  tne 
simple  solution  into  tne  restrictive  environment.  Tde  size 
of  tne  system,  tne  interface  requirements,  ana  tne 
restrictive  data  base  view  will  cause  tne  conceptual  aesisn 
to  be  tailored  and  modified  to  operate  in  tne  selective 
environment. 

2.  Data  Base  Considerations 

Tne  target  card  data  provides  tne  entities  (or 
records),  attributes  and  reiatlonsnlps  of  a  aaia  base 
system.  Tne  controlling  software,  tne  lata  base  management 
system  (DBMS),  would  normally  contain  language  facilities 
for  defining  tne  data  base,  for  manipulating  tne  lata  base 
information  and  for  obtaining  Information  from  tne  data 
base.  Tnis  last  facility,  tne  nlgn  level  query  language. 


allows  tne  user  to  manage  tfie  information  of  tne  data  tase 


and  perform  tne  required  operational  functions. 

Tde  lata  base  concept  enaoies  tbe  user  to  store  tne  lata 
In  space  saving  and  efficient  ways.  Redundancy  of  data  can 
be  eliminated  and  lata  items  deleted  wnicn  can  be  implicitly 
derived  from  otner  data  items.  Tne  system  allows 
''onstructlon  of  different  views  of  tne  lata  so  tnat 
different  users  can  perform  different  functions  on  tne  same 
type  of  data.  Applications  programming  Is  simplified  since 
it  only  needs  to  specify  parameters  to  tne  1;3"^S  wnicn 
locates  and  fetcnes  tne  lata. 

Tnus,  tne  design  of  tne  data  base  portion  of  tne 
'conceptual  system  will  require  tne  construction  of  tne 
logical  and  tne  pnysical  view  of  tne  information,  definition 
of  the  Information  in  terms  of  tne  lata  base  definition  and 
manipulation  languages  and  providing  a  LBI^S  witn  a  facility 
for  query  lan?ua?e  translation  to  operate  on  tne  data  base. 

3.  Applications  Program  Considerations 

The  user  environment  remains  as  defined,  a  friendly, 
sopnistlcated  Interactive  man-macnine  interface.  Tne 
applications  proeram  must  interact  witn  the  user  and  witn 
tne  DBMS.  Tne  use  of  a  query  language  for  tne  parametric 
user  would  require  tne  user  to  learn  tne  data  base  query 
language.  Alternative ly, a  collection  of  query  language 
statements  could  be  imbedded  in  tne  applications  program  and 
selected  by  tne  user  utilizing  tne  menu  selection  interface. 


Tsese  statements  would  interact  directly  witn  tne  ^3^'S. 
Additionally,  tne  cost  lan^ua^e  could  oe  extended  to  enacle 
it  to  pass  information  to  tne  TBr^S  in  tne  form  of  a 
procedure  call. 

Tne  requirement  for  menus,  nelp  functions  and  system 
explanations  could  oe  effectively  solved  by  tne  use  of 
user-oriented  utility  modules  wnicn  could  be  accessed  as 
needed.  Tne  basic  conceptual  system  design  derived  from  a 
top-down  view  of  tne  target  information  system  tasic  is 
depicted  in  figure  5.  Tnls  basic  design  will  be  refined  to 
fit  wltnin  tne  solution  environment. 


Fieure  5.  Design  of  tne  Conceptual  Model. 

B.  PRSLIMINART  CONSIDERATIONS  FOR  SYSTEM  DESIGN 

Vfltn  tne  basic  frameworit  laid  out  by  tne  conceptual 
model,  tne  tasK  now  becomes  one  of  attempting  to  Insert  tnis 
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classic  approacn  design  into  tne  restricted  environment  of 
tne  Ticrocomputer.  Tr.is  reauires  a  nisr.  de^r^e  of 
specificitv  in  order  to  identify  tne  tools  to  be  employed  in 
tne  implementation  and  tne  metnodolocy  of  employing  tnose 
tools.  Tne  target  macnine  must  be  identified  to  precisely 
define  tne  microcomputer  constraints.  Tne  data  base  model 
and  its  pnysical  and  logical  organization  must  be  defined, 
tne  applications  program  functions  and  tasK  flow  analysis 
must  be  determined  and  tne  target  programming  language  must 
be  identified. 

C.  HARDWARE  SELECTION 

The  selection  of  tne  system  hardware  was  driven  by  tnree 
considerations.  First,  it  nad  to  be  a  commercially 
available,  typically  configured  microcomputer.  Sucn 
generality  is  needed  if  tne  system  was  to  be  transportable 
to  otner  microcomputers.  In  tne  search  for  a  typical 
microcomputer,  an  effort  was  made  to  avoid  tne  nome  or 
personal  computers  wnlcn,  wniie  small,  easily  transportable 
and  Inexpensive,  possess  neither  the  processing  power  nor 
tne  virtual  memory  capacity  needed  for  tne  system. 

The  second  consideration  was  for  a  computer  that 
possessed  acceptable  size  and  weignt  cnaracteri st i cs  for 
transportability,  nad  a  compact  configuration,  was  generally 
rugged  for  a  commercial  product  and  nal  sufficient 
processing  capacity. 
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Tbe  tftlrl  conslleracion  iias  avaiiaDiiiiy.  Tr.e  ALTOS 
ACS-S0i}0  is  a  representative  of  micro-systems  commercially 
availablet  and  nas  selected  for  use  in  tnis  worir.  Tne  ALTOS 
microcomputer  conforms  well  to  tne  desired  computer 
cnaracterlstlcs .  LCDR  D.  L.  Smitn  in  r.is  thesis  entitled 
Method  to  Evaluate  Microcomputers  for  Non-tactlcal  Shipboard 
Jse  cited  tne  ALTOS  as  one  of  the  top  four  mi-'rocompu ter 
systems  evaluated  and  found  it  suitable  for  use  on  U.S.  Navy 
snips. 

Tne  ALTOS  ACS-8000-1  is  a  single  board  Z-B0A  based 
microprocessor  witn  54K  bytes  of  random  access  memory  and 
two  Snu^’art  SA-800/901  elgnt  Incn,  single  side  floppy 
diskette  drives  contained  within  tne  16  by  7  by  17  incn 
compartment.  It  requires  a  CRT  for  Input/output  and  supports 
12B  characters  of  upper  and  lower  case  ASCII  with  50 
cnaracters  per  line  on  a  24  line  video  display.  Tne  computer 
weighs  approximately  35  pounds,  nas  a  forced  coollne  system, 
utilizes  standard  115  volt  electric  power  with  a  cattery 
baclcup  and  operates  within  a  temperature  range  of  32-105 
degrees  farennelt  and  a  numidlty  range  of  10-y0  percent. 

The  two  floppy  diskettes  with  tne  IBM  3740  single 
density  format  ana  tne  64X  of  main  memory  gives  a  total 
memory  space  of  576K  bytes.  The  nlgn  level  language  support 
for  tne  ALTOS  Includes  tne  CP/f*  operating  system,  Basic, 


FORTRAN,  Pascal,  PL/I-S0,  APL,  LISP,  COBOL  and  the  Micro 
Data  Base  Systems  DBMS  for  a  microcomputer. 


D.  ?R0GRi!^'^lN3  LANCJUASS  SfiLJECTION 

The  selection  of  a  programming  language  was  influenced 
oy  tnree  major  considerations.  First,  tne  nardware  selected 
and  the  availaoliity  of  assemblers,  interpreters  and 
compilers  to  support  a  programming  project  on  this  nardware 
narrowed  tne  field  considerably.  Second,  taere  was  a  desire 
to  use  a  language  wnicn  is  relatively  self-explanatory, 
self-documenting  and  transportable.  And  finally,  tne 
language  would  nave  to  support  a  robust,  user-oriented 
interactive  program. 

Of  the  available  languages,  Pascal  was  selected  for  a 
number  of  reasons.  It  has  features  wnicn  maice  it  readily 
useable  for  systems  and  applications  programming  in  that  it 
is  "strongly  typed",  requiring  explicit  data  declaration.  It 
forces  the  data  base  to  be  completely  designed  before  tne 
source  program  is  written. 

Pascal's  structure  encourages  modularity  as  well  as 
top-down  design  and  implementation.  It  is  a  relatively 
simple  language  and  Is  tne  basis  for  tne  proposed  Department 
of  Defense  standard  nlgn  order  programming  language,  Ada. 
The  most  popular  version  of  Pascal  for  microcomputer  use  is 
tne  University  of  California  at  San  Diego  (UCSD)  version 
developed  by  the  University's  Institute  for  Information 
Systems. 

The  UCSD  (Mini-Microcomputer)  Pascal  version  1.4b  Is  a 
system  intended  to  run  on  a  stand-alone  mini  or 


mlcroconpute r.  It  is  nlgniy  macalne  independent  since  it 
runs  on  a  pseud o-macnlne  interpreter.  Tne  system  contains  a 
compiler,  linger,  screen  oriented  editor  and  an  operating 
system  wnicn  are  compatlOie  wl  tn  Z-?4?  microprocessors  tnat 
operate  under  tne  Digital  Researcn  CP/''  operating  system. 

Because  of  tne  microcomputer  environment,  mere  are  a 
number  of  differences  between  tne  UCSD  Pascal  and  tne 
standard  version  of  Pascal  as  defined  by  Jensen  and  Wlrtn. 
Particularly  nelpfui  are  a  number  of  string  Intrinsics, 
random  access  of  flies  by  a  SEEK  command,  file  nandilng 
commands  and  seement  procedures.  Tne  segment  procedure 
capability,  for  example,  enables  tne  user  to  segment  tne 
applications  prosram  into  a  main  program  and  up  to  six 
procedure  modules  wnicn  are  retrieved  from  secondary  storage 
when  called.  This  allows  a  laree  portion  of  the  program 
object  code  to  reside  on  dlst  wnen  not  needed,  inus, 
Increaslne  the  size  of  main  memory  for  computation  and 
operating  system  functions. 

E.  DATA  BASE  CONSIDERATIONS 

Tne  design  of  tne  pnyslcal  and  logical  data  base  is 
addressed  in  detail  in  the  next  chapter  and,  accordingly, 
tnis  section  will  address  only  those  items  of  Importance  to 
the  system  design.  In  tnat  tne  user  view  of  the  scnema  and 
tne  conceptual  view  of  tne  scnema  are  identical,  and  because 
there  is  no  requirement  for  an  integrated  data  base,  tae 
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traditional  lata  models  (relational,  nierarcnial  and 
networic)  will  not  oe  employed. 

Consideration  was  given  to  using  existing  DEMS  systems 
for  tne  target  information  system  but  tney  were  rejected  for 
essentially  two  reasons.  First,  tne  target  information 
system  is  a  restricted,  single  application  data  base.  It  is 
sufficiently  restricted  tnat  a  general  purpose, 
multi-faceted  data  base  management  system  is  not  required. 
Second,  tne  use  of  a  DBMS  query  language  was  considered  botn 
time  consuming  and  difficult  to  learn  for  tne  system  user 
and  unnecessarily  complicated  tne  interface.  Tnis  is 
especially  true  because  the  system  is  designed  to  limit  tne 
type  of  queries  allowed  on  tne  data  base. 

By  extending  tne  nost  language  from  tne  applications 
program  to  tne  data  base,  data  Independence  is  lost. 
However,  since  tne  system  will  not  allow  tne  user  to  access 
tne  data  base  in  any  way  otner  tnan  tnat  specifically 
allowed  by  the  system  interface  design  and  since  mere  is 
only  one  view  of  tne  data,  tnis  does  not  present  a  problem. 

Tne  data  base  will  consist  of  two  flies.  Tne  first  is  a 
flat,  relational  model  representation  wltn  tne  target  as  a 
single  record  and  the  target  information  pertinent  to  that 
specific  target  as  tne  attributes  of  tnat  record.  All  of  tne 
active  and  inactive  targets  will  be  contained  in  this  main 
target  file.  Tne  second  file  will  be  tne  data  base  query 
file  consisting  of  tne  primary  and  secondary  Keys  for  each 
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target.  Tne  standard  system  queries  will  return  information 
in  the  tareet  list  format  and  will  ootain  all  tn®  necessary 


data  from  tne  data  ease  query  file. 

This  partition  of  data  base  flies  increases  tne  data 
redundancy  of  tne  system  since  all  tne  data  in  tne  query 
file  is  duplicated  in  tne  main  file.  However,  tnis  is  done 
to  Improve  tne  system  response  time  to  user  queries  by 
greatly  reducing  tne  dlsic  accesses  taat  would  nave  been 
required  to  process  tne  main  file.  This  tradeoff  is  made  in 
favor  of  tne  user  interface  and  at  tne  expense  of  additional 
storage  space  and  Increased  program  complexity. 

Tne  secondary  Keys  used  to  process  tne  target 
information  queries  (priority,  classification,  type,  etc.) 
are  contained  in  tne  in  tne  data  base  query  file.  An  index 
file  containlne  tne  addresses  of  the  tareet  records  is 
constructed  in  main  memory  at  tne  beginning  of  tne  program, 
thus,  ellmlnatlne  the  need  for  a  separate  record  address 
file  and  reducing  tne  number  of  disK  seeks  required  to 
access  a  record  from  tne  main  tareet  file.  Vere  tnis  not 
done,  tne  system  would  nave  to  access  an  address  index  file 
In  secondary  storaee  to  obtain  the  address  and  tnen  access 
tne  record  in  tne  main  target  file  in  secondary  storage  to 
Obtain  tne  record.  Having  tne  index  in  main  memory  requires 
only  one  access  to  tne  disk,  tne  access  for  tne  actual 
record . 
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The  moluies  of  the  appiicdtioas  proeran  directly 
interface  to  tne  data  base  files  accessing,  manipulating  and 
rewriting  the  lata  as  necessary.  Tne  system  performs  data 
base  operations,  not  lata  base  management  and  is  an 
extension  of  tne  host  language. 

?.  USSR  INTERFACE  CONSIDERATIONS 

In  the  preceding  cnapter,  tne  user  interface  was  defined 
and  the  general  requirements  determined.  These  reouirements 
are  now  translated  into  specific  design  parameters  for  tne 
target  information  system.  Additional  discussion  of  the  user 
interface  and  details  of  tne  dialogue  techniques  used  are 
presented  in  depth  in  chapter  VI. 

The  user  interface  is  characterized  by  four  major 
attributes : 

1.  All  communications  between  tne  user  and  tne  computer  is 
through  menus,  if  a  simple  command  is  adequate,  or  tnrougn 
interactive  computer  initialed  dialogue  for  more  extensive 
data  entry. 

2.  Extensive  help  is  available  at  ail  times.  This  help 
includes  explanations  of  tne  options  available,  tne  format 
of  the  required  input  and  examples  of  tne  correct  input. 

3.  The  display  processing  time  is  as  snort  as  possible  to 
remain  within  the  constraints  of  snort  term  memory 
retention  and  logical  closure. 
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4.  Tae  user  is  restricted  to  the  system  defined  options 
for  data  Input  and  data  and  Information  retrieval.  Tnus , 
only  those  procedures  defined  by  the  system  through  tne 
menus  and  tne  dlalo^?ues  can  be  used. 

G.  APPLICATIONS  PROGRAM  CONSIDERATIONS 

Tne  metnodo logy  of  applications  program  aeslfi’n 
encompasses  three  separate  but  Interrelated  areas,  earn  of 
which  Is  continually  influenced  by  tne  system  aeslea 
environment.  These  areas  are  semantic  structure  design, 
syntactic  structure  design  and  software  design. 

In  the  top-down  semantic  design  stage,  tae  system  goals 
were  translated  Into  the  applications  program  eoais  and  the 
system  functions  and  requirements  were  determined, 
categorized  and  prioritized.  Tne  tasK  flow  of  tne  system  was 
analyzed  and  alternatives  developed  and  compared.  The 
selection  of  tne  most  effective  solution  to  eaca  of  tne 
problems  posed  by  tne  system  requirements  was  expressed  as  a 
functional  module.  This  module  was  then  further  broten  down 
Into  smaller  modules  whlca  address  particular  parts  of  the 
functional  requirement.  The  data  structures  and  control 
structures  were  then  determined  which  best  enable  these 
modules  to  perform  the  required  functions. 

The  design  of  tne  syntactic  structures  paralleled  tnat 
of  the  semantic  structures  and  Involved  tne  determination  of 
display  formats  from  a  comparison  of  different  approacnes  to 


the  user  Interface.  In  addition  to  display  formats,  system 
response  formats,  error  liairnostlcs ,  user  ails  and  help 
facilities  were  also  specified. 

The  software  was  designed  in  a  top-down  modular  fashion 
and  best  use  was  made  of  tne  facilities  of  tne  UCSD  Pascal 
system  segment  procedures  as  well  as  tne  structured  approach 
provided  by  the  Pascal  lan<ruaffe. 

The  target  information  system  applications  program 
consists  of  six  major  modules.  The  primary  module  is  the 
Interface  module.  It  acts  as  tne  executive  of  tne  program 
and  controls  tne  interaction  of  the  user  Input/output,  the 
data  base  operations  and  tne  segment  procedures. 

The  remaining  modules  are  segment  procedures,  that  is, 
they  reside  in  secondary  storage  until  called  into  main 
memory  by  a  procedure  invocation.  Upon  invocation,  tney  are 
read  into  main  memory  and  computation  continues.  When 
control  is  returned  to  tne  calling  procedure  (in  this  case, 
the  Interface  module),  the  memory  space  is  deallocated.  The 
UCSD  system  allows  up  to  six  of  these  segment  procedures  and 
permits  them  to  be  nested  in  order  to  further  reduce  the 
amount  of  code  necessary  in  memory. 

Tne  Initialize  module  is  used  wnen  tne  data  base  system 
is  Initialized  and  a  new  tareet  file  is  created.  The  Query 
module  contains  tne  menus  and  tne  semantics  for  tne  system 
queries  to  the  data  base  query  file.  It  is  used  only  when 
target  information  by  specific  parameter  is  desired  by  tne 
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TID.  k  Otlllty  moluie  contains  a  number  of  nouseiceeping 
routines  for  constructlne  toe  TARBUL,  leterminlne  target 
file  status,  copying  tne  data  oese  to  another  diskette, 
printine  tareet  ilsiines  and  otner  functions. 

The  Target  module  is  tne  major  segment  procedure  and  is 
used  for  addins,  deleting  and  chan<fine  tareets  in  tne  main 
target  file.  It  also  updates  tne  data  base  query  file  and  if 
necessary,  the  TARBOL  file.  The  Inform  module  contains 
user-oriented  information  concerning  doctrinal  terminology, 
systems  instructions,  version  inform, atlon  and  tactical 
guidelines. 

The  target  information  system  design  is  illustrated  in 
figure  6.  Because  much  of  tne  design  was  influenced  by  the 
microcomputer  constraint,  tne  amount  of  object  code  resident 
in  memory  at  one  time  has  been  minimized.  The  illustration 
in  figure  7  snows  tne  expected  allocation  of  secondary  and 
main  memory  for  the  system,  (see  pages  64  and  65^ 

H.  SSCaRITT  AND  INTEGRITT 

Security  for  the  system  is  essentially 
non-dlscretlonary .  Tne  system  is  secure  because  it  is 
located  in  a  secure  area  (the  FSCC  is  usually  a  restricted, 
controlled  access  area  within  a  secure  perimeter).  Tne 
targets  contained  in  the  list  of  targets  are  typically 
classified  confidential  and,  therefore,  tne  diskettes  would 
be  considered  classified  matter.  Thus,  tne  usual  precautions 
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anl  practices  for  tne  security  of  classified  material  are 
sufficient  for  tne  system. 

As  a  further  safeguard  and  security  feature,  tne  system 
will  nave  a  user  password  wnlcn  will  allow  only  bonaflle 
individuals  to  access  tne  data  oase  of  targets.  Input  or  an 
Improper  or  erroneous  password  will  Keep  tne  user  in  tne 
outer  eiee  of  tne  Interface  module  and  prevent  opening  tne 
data  base  Index  file  wltnout  wnlcn,  tne  data  cannot  be 
accessed.  The  Utility  module  has  a  subroutine  which  allows 
tne  user  to  specify  nis  own  passwords. 

The  target  Information  system  will  reside  on  an  eight 
Inch  floppy  dlsKette  wnlcn  will  contain  tne  Pascal  operating 
system  and  the  object  code  of  tne  applications  program.  Tne 
source  code,  editor  and  compiler  will  be  removed  from  tne 
diskette  to  prevent  any  user  from  modifying  or  changing  any 
part  of  tne  system.  Tne  user  can  only  change  tne  password 
and  the  target  Information. 

Upon  activation  of  the  system,  a  user  advisory  messaee 
will  be  printed  on  the  CRT  screen  Informing  tne  user  of  nis 
responsibility  to  safeeuard  the  classified  Information.  All 
of  the  printed  output  of  tne  system  will  contain 
confidential  marKlnes  on  each  pa«e  as  required  by  current 
security  regulations. 

Nuclear  and  chemical  target  Information  and  analysis 
will  be  excluded  from  tne  target  information  system  and 
processed  in  accordance  with  current  procedures.  This  Is 


done  primarily  because  tnese  targets  require  special 
tecbnlques  for  analysis,  are  typically  of  a  nigaer 
classification  tnan  confidential  and  are  of  sucn  a  decree  of 
sensitivity  tnat  special  nandlln^  is  usually  required. 

I.  TRANSITION 

A  Key  element  of  tne  system  Is  tne  pnyslcal  am  logical 
design  of  tfte  data  base.  Since  tfte  system  is  functionally 
restrictive,  tne  data  base  nas  been  designed  to  provlae 
optimal  performance  to  tne  user.  Tnis  nas  resulted  in  desien 
parameters  wnicn  are  explained  in  deptn  In  tne  next  cnapter. 
The  chapter  develops  some  of  tne  important  considerations  of 
data  base  tecnnology  and  tne  methodology  of  data  base 
selection  and  file  determination.  Tnese  techniques  were  used 
to  design  tne  loelcal  target  information  record. 

System  and  environmental  requirements  impact 
significantly  on  tne  pnyslcal  data  base  design  and  a  number 
of  alternatives  are  presented  and  evaluated.  Tne  pnyslcal 
record  design  as  well  as  tne  Inverted  file  Indices  are 
described  la  detail  and  provide  a  justification  for  tne 
system  design  presented  In  tnis  cnapter. 
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7.  DATi  BASE  DESIGN 


A.  PRELIMINARI  DESIGN  PROCESS 

Before  tne  lesl^rn  of  tne  pnyslcai  ana  tne  io^icai  data 
base  can  proceed,  tnere  are  certain  ground  rules  and  design 
criteria  ttiai  must  be  estabiisnel.  Data  base  tecfinoloey  nas 
become  more  formalized  in  tne  past  ten  years  wltn  general 
acceptance  of  tnree  major  data  models,  tne  relational,  tne 
nierarcnial  and  tne  network  or  CODASTL.  Tne  task  now  becomes 
one  of  determining  tne  content  of  tne  target  Information 
data  base  and  wnicn  of  tne  major  lata  models  is  most 
appropriate  for  tne  detailed  design  of  tne  logical  and 
physical  data  base. 

1 .  Data  Base  Concepts 

Perhaps  the  initial  starting  point  should  be  a 
definition  of  tne  lata  base.  One  of  me  most  often  quoted 
sources  Is  James  Martin's  from  nis  Computer  Data-base 
Organization ; 

A  data  base  may  be  defined  as  a  collection  of 
Interrelated  data  stored  toeetner  with  as  little 
redundancy  as  possible  to  serve  one  or  more  applications 
in  an  optimal  fasnion;  the  data  are  stored  so  tnat  they 
are  Independent  of  programs  which  use  the  data." 

It  is  Important  to  dlstlngulsn  between  a  data  base 
system  and  a  file  system.  A  file  system  organizes  the  data 
storage  capability  wnicn  is  provided  by  tne  nardware  or 
operating  system  software.  The  hardware  Is  partitioned  Into 


flies  wnlcft  are  associated  witti  a  particular  user  or  for  a 
specific  purpose.  Operations  on  one  file  are  done  in 
Isolation  from  tne  otner  flies  (or  otner  users).  Tnus.  to 
access  the  same  Information  from  many  similar  files  may 
retiulre  as  many  separate  operations  as  mere  are  files. 

k  data  base  system,  on  tne  otner  hand,  organizes  tne 
file  storage  capability  ytilcn  is  provided  by  the  file 
system.  Tne  relationship  between  elements  or  entitles  of  tne 
file  are  mads  accessible  to  the  system.  The  user  jrains 
access  to  ail  of  tne  data  because  it  is  now  available 
through  relationships  to  other  data.  Additionally,  different 
users  can  access  the  same  data  and  snare  It. 

Access  to  the  data  base  is  provided  by  a  lata  language, 
a  set  of  operations  which  permit  access  to  the  data  that  has 
been  organized  by  a  lata  model.  Data  base  management  systems 
are  generally  classified  by  the  way  they  provide  access  to 
the  data.  A  self-contained  system  provides  all  the 
capabilities  and  required  services  by  itself,  typically, 
through  a  query  language.  Host-based  systems  carry  out  the 
retrieval  and  update  functions  only  and  deliver  tne  data  on 
request  to  programs  written  in  the  host  system  language. 
Occasslonally,  tne  nost  language  is  extended  to  operate 
directly  with  the  data  base,  but  usually  with  a  loss  of  data 
Independence . 
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Data  Base  Terminology 

Baca  of  the  major  data  models  refers  to  concepts  of 


data  la  silgntly  different  terminology.  For  example,  tne 
physical  record  type  "target”  consisting  of  target  number, 
grid  location,  altitude,  priority,  classification  and 
description  Is  called  an  entity  by  one  model,  a  segment  or  a 
logical  record  by  another  and  a  tuple  by  tae  tnird.  To  avoid 
confusion  and  misunderstanding,  a  set  of  terms  which  are 
partially  intuitive  In  nature  and  generally  from  tne 
relational  model  will  be  used.  These  terms,  their 
definitions  and  an  example  from  toe  target  information 
system  are  as  follows: 

Record . a  eroup  of  one  or  more  data  items  or  attributes 

which  corresponds  to  a  simple  record  or  entity  [a 
tareet] 

Attribute . tne  smallest  unit  of  data,  a  data  field  with 

a  certain  value  [target  AA0001  wltn  tne  "orlorlty" 
attribute  nas  value  IIIJ 

Relationship . tne  connector  between  individual  records 

of  the  same  type  or  croups  of  records  of  different 
types  [tne  list  of  targets] 

Relation. ....  the  set  of  all  records  of  a  elven  type  [the 
list  of  targets] 


e>8 


Degree . tne  number  of  attributes  In  a  record  Ifor  a 

record  wltn  tareet  numberi  location,  priority, 
classification  and  description,  the  degree  of  the 
record  would  be  5  J 

Cardinality . tne  number  of  records  in  a  relation  [tne 

number  of  targets  in  the  system] 

Domain . tne  set  of  all  possible  values  for  an  attribute 

[priority  has  domain  I,  II,  111,17] 

Primary  Key . one  or  more  attributes  of  a  record  wnose 

value  uniquely  identifies  the  record  [target  number 
AA0046] 

Secondary  Key . an  attribute  wnicn  may  or  may  not 

uniquely  identify  tne  record  but  wnicn  defines  a  set 
on  tne  record  [all  priority  I  targets] 

Schema . the  structure  of  tne  entire  data  base 

Subschema . that  portion  of  tne  schema  viewed  by  a 

particular  user  or  group  of  users 

Flat  file . a  relation  in  normal  form:  a  slnele  level 

record  array  with  only  one  record  type 

3.  File  Determination 

Tne  total  volume  of  data  in  tne  target  information 
system  must  be  viewed  with  the  objective  of  splitting  It 
into  smaller  units  that  may  be  considered  tne  basis  for 
or«anl2ln<r  the  data  base  file.  Having  already  determined  the 
system  functions  from  chapters  III  and  17,  tne  data  objects 
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and  tfte  relaiionsnips  to  perform  tfiese  functions  must  Se 
determined  and  organized.  Ttie  results  of  tnls  organization 
will  become  tne  criteria  for  tne  modular  design  of  tne 
applications  program. 

William  House  in  Data  Base  Management  provides  an 
excellent  metnodoloey  for  file  determination.  Data  splitting 
separates  tne  system  information  into  subsets  wnicn  can  be 
dealt  wltn  more  or  less  independently  and  pernaps  made  an 
independent  file  of  tne  data  base.  Record  design  determines 
tne  format  of  tne  content  to  appear  in  eacn  record  and  tne 
modes  of  Indeiine  In  order  to  establisn  tne  index  data  that 
must  be  present. 

Tolume  analysis  estimates  the  size  of  the  individual 
record  and  tne  size  of  tne  record's  relation  (cardinal! tyK 
The  physical  distribution  of  tne  number  of  records  in  eacn 
file  must  also  be  taxen  into  account  to  determine  tne  space 
management  requirements.  Activity  analysis  determires  the 
frequency  of  reference  and  estimates  tne  total  activity  for 
the  records  of  eacn  file.  It  Is  this  analysis  tnat  is 
essential  to  tne  question  of  file  design  and  one  of  tne  tey 
considerations  in  tne  microcomputer  environment, 
particularly  tne  access  bottienecic  to  secondary  storage. 

File  design  Is  dependent  upon  tne  record  structure, 
pnyslcai  distribution  of  tne  records  in  tne  storage  device 
and  tne  Indexing  method  employed  in  referencing  tne  record. 
Tne  critical  Issue  for  file  design  Is  Its  performance. 


4.  File  Performance 

There  are  a  number  of  criteria  which  must  ce 
considered  wnen  estimating  tne  performance  of  tne  file 
design.  There  will  inevitably  be  a  trade  off  between  storage 
space  and  processing  speed.  There  are  instances  wnen  tne 
rapidity  of  access  to  information  in  the  data  base  Is  more 
important  than  saving  or  optimally  utilizing  tne  secondary 
storage  space.  This  may  mean  redundancy  of  data. 

Glo  Vledernold  in  Database  Design  outlines  seven 
measures  of  file  performance.  These  parameters  were 
considered  wnen  designing  tne  physical  data  base.  These 
measures  of  file  performance  Include: 

1.  Storage  required  for  a  record 

2.  Time  to  fetch  an  arbitrary  record  from  tne  file 

3.  Time  to  eet  the  next  record  within  tne  file 

4.  Time  to  update  by  inserting  a  record  into  tne  file 

5.  Time  to  update  by  changing  a  record  In  the  file 

6.  Time  for  exhaustive  readlne  of  the  file 

7.  Time  for  reorganization  of  tne  file 

5.  Architectural  Perspective 

The  data  base  system  architecture  is  also  an 
Important  consideration.  It  depicts  the  natural,  conceptual 
and  physical  views  of  tne  data  in  tne  data  base.  It  Is  tne 
icey  to  data  Independence  and  gives  the  DBMS  much  of  Its 
power  and  flexibility. 

At  tne  most  abstract  level,  there  Is  tne  external  data 
base.  This  Is  the  way  In  which  the  user  views  the  data  base. 
It  consists  of  any  number  of  different  perspectives  of 
Individual  users,  which  are  considered  subschemas  of  the 
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data  base.  Typically,  tne  subscneinas  are  more  important  toan 
an  overall  view  of  me  external  data  since  tney  define  tne 
information  environment  for  a  single  user  or  specific 
application. 

The  external  data  base  maps  into  tne  conceptual  data 
base  which  is  the  lopical  view  of  the  information  contained 
in  the  data  base.  It  is  tne  schema,  or  combination  of  all 
the  subschema  expressed  In  the  logical  format  of  a  lata 
model.  It  consists  of  tne  records,  relations  and 
relationships  of  the  data  as  well  as  the  primary  and 
secondary  Keys  used  for  processing  tne  data  base. 

The  conceptual  level  maps  into  tne  internal  data  base, 
which,  as  tne  physical  view  of  tae  data,  is  tne  least 
abstract  level  of  the  architecture.  The  physical  lata  base 
contains  tne  records,  files,  indices,  inverted  flies  and 
record  sequences  of  the  data  base.  Kn  illustration  of  tne 
different  levels  of  tne  data  base  system  architecture  is 
shown  in  figure  9. 
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Figure  9.  Data  Base  System  4rcaltecture . 


6.  Types  of  Systems 

Tae  discussion  so  far  aas  malniy  considered  tne  data 
oase  management  system  concepts  for  tne  target  information 
system.  Given  tae  nature  of  tae  target  information  file  and 
tae  system  environment,  otner  types  of  systems  near 
consideration.  A.n  appropriate  alternative  to  a  general 
purpose  DBMS  mlgnt  be  a  single  application  system. 

A  single  application  data  base  system  establlsnes  an 
operation  using  tae  available  file  system  facilities  and 
designs  applications  programs  wnlcn  interface  to  tne  data 
base.  A  system  for  tae  routine  processing  of  data  and  tae 
answering  of  a  prespecified  and  limited  class  of  Queries  is 
sometimes  referred  to  as  an  operations  system.  Tais  type  of 
system  is  designated  for  a  precisely  defined  and  limited  set 
of  operations. 
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In  a  data  base  manairement  system  (DBMS),  an  information 
system,  tne  nature  of  tne  queries  will  not  be  pre-iefinea  by 
the  system  and  ienstny  searches  may  be  necessary  wnen  a 
query  is  male.  Tne  capability  to  process  generally  stated 
queries  is  characteristic  of  the  multi-purpose  design  of  tne 
DBMS  and  often  accounts  for  its  relatively  large  size  and 
cost.  In  an  operations  system,  lensrtny  searches  can 
generally  be  avoided  because  tne  Information  is  typically 
stored  in  the  form  it  is  needed.  The  t»fO  types  of  systems 
use  data  bases  wnlcn  are  differently  structured  botn 
logically  and  physically. 

B.  LOGICAL  data  BASE  DESIGN 
1 .  Data  Splitting 

Given  the  total  information  in  tne  target 
information  system,  or  more  precisely,  tne  set  of  aata  that 
represents  this  Information,  it  is  necessary  to  separate  it 
into  subsets  which  can  be  dealt  wltn  more  or  less 
independently. 

Tne  information  for  tne  system  comes  from  tne  target 
card.  Ail  of  tne  information  pertinent  to  tne  data  base  is 
on  tnat  card  or  can  be  implied  from  it.  A  biocn  record  of 
all  of  this  lata  pertinent  to  tne  system  can  be  visualized 
in  figure  9. 
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TARGET  NOMBER 

GRID  LOCATION 

altitude 

TARGET  TYPE 

ARM  ASSIGNED 

ACCURACY 

ATTACKED? 

FIRING  ONIT 

PRIORITY 

CLASSIFICATION 

DESCRIPTION 

DTG  ACTIVE 

PHOTO  N(ir-BER 

PHOTO  COORDINATES 

BDA 

MAP  REFERENCE 

TARGET  LIST? 

REMARKS 

DTG  ATTACKED 

NO. TYPE  ROUNDS 

STATUS 

DAMAGE  REPORTED 

DAMAGE  ASSESSED 

SOURCE 

Figure  9.  Target  Information  Conceptual  Record. 


The  data  can  logically  be  split  into  different  seements, 
for  example,  description  information,  surveillance 
Information,  status  information  and  source  information,  but 
a  consideration  of  tne  user  and  tne  conceptual  view  of  tne 
system  Is  necessary  first. 

Tnere  is  only  one  user,  tne  target  information  officer 
and  be  bas  only  one  view  of  me  data,  taat  of  tbe  target 
card.  He  may  use  tnat  data  differently  depending  upon  tne 
tactical  situation  or  Internal  operating  procedures  but  bis 
logical  view  of  it  nas  not  cnanged.  An  integrated  data  case 
will  have  many  users  and  many  different  views  of  the  data 
(one  schema  with  many  subschema).  The  target  information 
data  base  is  not  an  integrated  data  base  and  it  has  only  one 
user  and  one  view  of  the  data,  thus,  tne  schema  and  the 
subscnema  are  tne  same.  Tne  need  for  data  independence 
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(logical  data  la  tnis  case)  is  no  loneer  required  for  tne 
system  because  tue  external  view  is  equal  to  tne  conceptual 
view, 

Splittine  me  tareet  data  does  not  achieve  any  added 
flexibility,  simplicity,  independence  or  efficiency.  Thus, 
the  target  record  can  consist  of  tne  above  24  attributes,  ao 
other  relatl onsnlps  and  be  organized  as  a  flat  file. 

2,  Record  Design 

for  tnis  large  set  of  data  on  target  information,  a 
determination  must  be  made  of  the  format  of  the  record  and 
tne  modes  of  indexing  in  order  to  establish  tne  index  data 
tnat  must  be  present.  Two  alternatives  were  considered,  one 
with  a  flat  file  and  a  second  with  multiple  records.  The 
multiple  record  version  merely  added  more  complexity  and 
more  data  to  the  files  with  little  benefit  to  ibe  system 
otner  tnan  it  "looKed"  more  use  a  data  base. 

The  flat  file  appeared  to  be  tae  simplest  conceptually 
and  tne  easiest  to  implement.  The  data  witnln  tne  record  was 
ordered  in  a  functional  manner  for  semantic  purposes  and  tae 
primary  and  secondary  iceys  were  determined. 

Tnere  is  only  one  way  to  uniquely  identify  a  target  and 
mat  is  by  tne  target  number.  This  is  primarily  dictated  by 
doctrinal  procedures  since  tne  target  alpna/numeric 
combination  determines  the  orielnatlne  unit  as  well  as  a 
specific  target.  Target  grid  coordinates  may  be  considered 
as  an  additional  unique  Key,  However,  a  sincle  map  location 
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can  be  largeiel  for  multiple  purposes.  Tnerefore.  toe  target 
number  was  selectei  as  tne  primary  icey  for  ttie  recora. 

Tnere  are  a  number  of  secondary  Keys  for  eacn  target  out 
only  a  few  of  these  nave  a  real  meaning  to  tne  TIO.  Those 
keys  Which  will  be  needed  to  access  certain  types  of  target 
information  nave  been  selected  as  secondary  ireys .  It  is  for 
these  keys  tnat  tne  ^lueries  to  tne  data  base  will  le 
designed.  Figure  10  illustrates  the  primary  and  secondary 
Keys  of  tne  target  record. 


Figure  10.  Primary  and  Secondary  Keys. 

3.  Volume  and  Activity  Anal  s- 

Estimates  must  be  of  individual  record  sizes 

and  then  of  tne  expected  file  sizes  as  well  as  determining 
the  frequency  of  reference  of  information  in  the  lata  base. 
In  determining  record  size,  a  number  of  considerations  came 
into  play.  Data  items  which  could  be  derived  or  implied  from 
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otner  data  items  were  deleted.  For  example.  If  a  target  flad 
a  BDA  In  tne  record,  it  aad  been  attached  by  supporting 
arms.  If  mere  were  no  BTA,  the  tar/ret  had  not  been 
attaciced. 

Additional  attributes  were  identified  wnose  requirements 
were  implied  by  other  data  items.  For  example,  target  type 
was  made  a  record  attribute  (and  a  secondary  icey)  since  the 
target  description,  being  text,  would  nave  to  be 
semantically  analyzed  in  order  to  reveal  all  targets  of 
enemy  "artillery". 

Attempts  were  made  to  reduce  tne  size  of  stored  data  cy 
encoding  tne  domains  of  attributes.  The  domain  for  target 
priority  is  [I,  II,  III,  IVJ  .  To  place  priority  III  in  tne 
target  record  file  would  talce  three  cnaracters;  reduced  to  a 
numerical  representation,  it  taites  only  one  number  (3K 
Target  damage  is  described  by  a  maximum  of  eight  different 
words,  the  lareest  of  which  is  11  cnaracters.  This  has  been 
reduced  to  a  single  number  from  one  to  eight. 

A  data  dictionary  was  developed  which  listed  each 
attribute,  its  domain,  data  item  size  and  data  type  (see 
appendix  A).  From  this  document,  the  size  of  tne  record  was 
determined  to  be  approximately  240  bytes.  Since  adeviuate 
secondary  storage  appeared  to  be  available,  a  fixed  length 
record  was  selected.  In  addition,  since  more  than  one  BDA 
was  expected  for  a  given  target,  tne  record  size  was 
increased  to  three  BDA  per  target  bringing  the  record  size 
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10  approximately  370  bytes.  Wltft  a  maximum  of  300  lareets  in 
tne  system,  tne  file  would  occupy  appproximateiy  110£  bytes 
of  secondary  storage. 

in  estimate  was  male  of  tne  number  and  type  of 
references  to  tne  data  based  on  ^nown  ana  anticipated 
tactical  requirements.  A«ala,  tne  deslen  restrictions  on 
What  tne  user  could  asK  of  tne  data  oase  played  an  important 
consideration.  The  majority  of  tne  information  for  retrieval 
was  either  an  individual  target  carl  or  a  list  of  specific 
targets.  Return  of  the  target  card  to  the  user  was  a  simple 
matter  for  file  design,  merely  retrieve  tne  record  from  tne 
data  base  and  display  all  of  tne  information.  The  retrieval 
of  specific  information  is  more  complicated. 

The  specific  information  about  targets  is  best  displayed 
as  a  target  list  since  tnat  is  tne  most  useful  format  for 
the  user.  Figure  11  is  an  example  of  tne  format  required 
from  tne  data  base. 
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LIST  OF  TARGETS 


TGT  NO 

CL 

PR  I 

LOCATION 

ALT 

SA 

DESCRIPTION 

AA0021* 

C 

II 

34566543 

90 

AIR 

2  T-62  TANKS 

AA0020 

C 

17 

23455565 

40 

NGF 

5  INCH  COASTAL  GUN 

AA0056* 

E 

IV 

57665466 

50 

NONE 

4  SCHOOL  BUILDINGS 

AA0013* 

A 

III 

55677412 

15 

NGF 

BUNKERED  TRENCHLINE 

AZ1022 

D 

II 

76835454 

110 

ARTf 

BN  ASSEMBLY  AREA 

AZ1005» 

C 

I 

34345656 

20 

ARTY 

PLT  ZSU  23-4 

AA0012 

B 

III 

56445456 

10 

NGF 

concrete  bunker 

NOTE:  *  indicates  target  list 


Figure  11.  Example  of  a  Target  List. 


4.  Design  Conclusions 

Because  tne  data  base  is  a  single  application  data 
base  and  is  an  operations  system  ratner  tnan  an  information 
system,  me  use  of  a  specific  data  model  v^as  rejected.  Tne 
flat  file  format  lends  itself  to  tne  relational  Ttodel  and 
tne  resultant  system  approximates  tne  relational 
meinodology.  Tne  system  does  qualify  as  a  data  base. 
However,  it  is  a  very  restricted  one  due  to  its  specific 
purpose. 

Access  to  tne  data  base,  eiven  tne  limited  '•noice 
imposed  upon  tne  user  by  tne  system  design,  was  by  extending 
tne  nost  language  ratner  tnan  tne  use  of  a  query  language  or 
Imbedded  data  language.  Tne  record  design  incorporates  tne 
target  information  as  one  record  with  one  primary  and  seven 
secondary  Keys  for  a  total  of  22  attributes.  Tnis  monoiitnic 
record  is  depicted  in  figure  12. 
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Target  Description 


TGT  NO 

DESCRIPTION 

GRID  LOCATION 

ALTITUDE 

REMARKS 

5^ 


k: 


Target  Status  Inforr’ation 


SUPPPORTING 

ASSIGNED 


type 


PRIORITY 


CLASSIFICATION 


STATUS 


^  ©  ©  ©  ® 

Target  Surveillance  Information 


DTG 

FIRING 

NO/TTPE 

DAMAGE 

DAMAGE 

EDA 

ATTACK 

UNIT 

ROUNDS 

REPORTED 

ASSESSED 

■■■ 

Target  Source  Information 


MAP 

REF 


SOURCE 
OF  TGT 

DTG 

ACTIVE 

accuracy 

PHOTO 

NUMBER 

PHOTO 

COORD 

Figure  12.  Logical  Record  Design. 


C.  PHYSICAL  DATA  EASE  DESIGN 
1 .  System  Output 

Tne  system  output  must  ne  considered  tefore 
discusslne  trie  pnyslcal  data  base  design.  Ttiese  end-proiurts 
require  a  certain  content,  format  and  response  time. 
Retrieval  of  information  for  tHe  TIO  must  be  rapid  and  tbe 
pnyslcal  design  of  tne  data  must  facilitate  speed,  even  at 
tne  cost  of  storage  efficiency. 
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Tiiese  Itens  of  systen  output  nave  previously  been 
ilentified  and  are  depicted  schematically  in  figure  IS: 


Fleure  IS.  System  Output. 


2.  Index  File  Design 

The  choice  of  file  organization  is  dependent  upon 
the  record  structure,  the  physical  distribution  of  tr.e 
records  in  tne  storage  device  and  the  indexing  metnod 
employed  to  reference  the  record.  To  some  decree,  the  amount 
of  storage  space  available  will  influence  tne  file  design  as 
well.  The  critical  issue  is,  however,  the  efficiency  of  its 
performance. 

The  record  is  accessed  by  its  primary  Jcey.  Tne  target 
number,  unfortunately,  is  not  always  assigned  in  sequence. 
Taus,  there  is  no  logical  order  inherent  in  the  tareet 
number  although  they  could  be  ordered  in  numerical  sequence 
for  the  saite  of  order.  But  there  is  no  consistent  order  to 
warrant  tne  use  of  sequential,  indexed  sequential,  nasned  or 
binary  tree  storage  schemes.  The  use  of  the  dense  index 
allows  us  to  access  tne  required  target  efficiently  (wltn 
only  300  targets)  as  well  as  Insert  new  targets  easily  at 


the  end  of  the  file,  'rfhile  deletion  of  targets  n^ould  leave 


nodes  in  tne  storage  file,  an  unnsea  target  space  record 
could  be  Tiaintained  whim  would  icsep  tracK  of  the  holes  and 
assign  newly  inserten  records  in  tne  available  space. 

The  dense  index  would  nave  to  be  made  on  both  the  target 
number  and  tne  grid  coordinates,  since  it  is  a  doctrinal 
requirement  to  be  able  to  sort  on  both.  Tne  UCSD  Pascal 
Implementation  maices  tnis  a  muca  easier  operation  witn  its 
string  intrinsics  and  random  access  capability  of  relative 
records.  This  also  allows  tne  Index  to  be  stored  as  a 
subscripted  array  and  enables  the  system  software  features 
to  do  most  of  tne  manipulation.  The  index  design  is 
illustrated  in  figure  14.  It  is  essentially  two  arrays  each 
consisting  of  tne  target  number  or  tne  grid  location  for 
each  of  tne  allowable  ZdH  targets. 


Figure  14 


Target  File  Index  Design. 


Tne  ease  of  tae  UCSD  Pascal  random  access  capaclilty  is 
illustrated  in  figure  16.  Tne  SEEK  command  on  tne  file  name 
and  tne  record  number  provide  for  a  base  address  and  an 
offset  to  tne  required  target  number.  Tnis  allows  for  qulcK 
and  easy  access  to  any  target  requested  by  tne  user. 


Figure  15.  OCSD  Pascal  Random  Access  Capability. 
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3.  Payslcai  Dgslgn  Alternatives 

Tne  file  leslgn  will  permit  easy  anfi  efficient 
access  to  tne  target  record.  Tne  display  of  tne  target  card 
is  essentially  solved  by  tnis  design.  Wnat  remains  is  tne 
accessing  of  tne  important  attributes  for  tne  target 
listings  by  specific  parameter,  i.e.,  tne  queries  from  tne 
TIO. 

The  most  straieht-f orward  approach  is  to  access  all  of 
tne  required  data  from  tne  target  file.  An  efficient  method 
of  doinff  this  would  be  to  use  multl-linted  lists  tnrou«n  the 
appropriate  data  items.  Header  records  would  provide  a 
pointer  into  tne  file  and  linjcs  would  provide  access  to  each 
item  of  specific  data.  There  are  overnead  considerations  in 
this  approach,  particularly  in  rearranging  tne  linis  wnen 
adding  or  deleting  a  target. 

A  major  disadvantage  to  tnis  approach  is  the  estimated 
time  it  would  take  to  process  a  query.  If  all  priority  I 
targets  are  to  be  retrieved,  tne  program  module  must  find 
tne  header  index  and  follow  the  pointer  tnrouah  the  target 
file  until  it  found  eacn  of  tne  priority  I  targets. 

The  disk  accessing  to  secondary  storage  is  a  bottleneck 
in  a  microcomputer  and  snould  be  minimized  whenever 
possible.  The  access  time  to  find  all  priority  I,  class  C, 
previously  attacked,  tank  targets  could  oe  quite  lengtny. 
Arranging  tne  file  into  blocks  of  five  to  ten  target  records 
per  block  would  decrease  the  amount  of  disk  accesses. 
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A  second  approacn  would  oe  to  use  an  inverted  file 
structure  (often  used  In  data  oase  systems  to  improve  direct 
access  to  certain  data)  for  each  of  tne  secondary  Keys  with 
a  pointer  (actual  or  symbolic)  to  eacn  of  tne  specific 
records.  An  access  to  the  entire  inverted  file  index  would 
identify  by  name  or  by  location,  eacn  of  the  appilcacle 
records.  Once  determined,  the  records  could  be  retrieved. 

To  process  a  target  list  with  multiple  parameters,  only 
the  target  numbers  from  the  indices  need  to  be  read  into 
memory  and  tne  appropriate  intersection  made  of  tne  common 
record  attributes.  This  would  entail  one  seeK  per  index  and 
then  one  sees  for  eacn  appropriate  record.  Additional 
efficiency  is  obtained  if  all  tne  index  files  are  read  into 
main  memory  when  tne  user  is  going  to  mate  accesses  to  tne 
data  base.  This  will  reduce  the  number  of  dlsK  seeKs 
required  to  access  records  and  is  particularly  effective  for 
multi-parameter  queries. 

There  is  a  bit  more  efficiency  in  the  second  method, 
particularly  in  accessing  data  with  multiple  parameters  but 
the  cost  is  in  use  of  more  secondary  storage  for  the 
Inverted  files.  With  tne  amount  of  secondary  storage 
available  (see  the  estimate  in  fl^ue  7),  tne  trade-off 
between  storage  space  and  processing  speed  is  considered 
acceptable. 

A  third  alternative  is  even  more  expensive  in  terms  of 
secondary  storage  since  it  calls  for  redundancy  of  target 
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data.  A  subset  of  tae  irain  target  file  can  be  ferried  to 
provide  tae  lata  in  a  more  accessible  form.  Tae  file  would 
be  a  separate  record  extracted  from  tae  mala  target  file  and 
consist  of  only  taose  attrloutes  or  items  waica  will  be 
needed  for  tae  target  ouery  and  tae  resulting  output 
listing.  Tais  would  eliminate  tae  need  to  access  tae  main 
target  file  for  ;iuerles  since  all  tae  system  queries  would 
be  confined  to  tae  data  base  query  file.  Once  tae  target 
number  was  identified  by  tae  query  mecnanism,  tae 
appropriate  target  listing  information  would  be  '  obtained 
from  tae  file  and  displayed  on  tne  CRT  screen. 

Tais  data  base  query  file  would  nave  records  of  45  bytes 
in  lengtn  witn  a  maximum  file  size  (for  300  targets^  of 
about  145  bytes.  Tae  logical  record  is  illustrated  in  figure 
16.  To  access  tae  data  in  tais  file,  tne  inverted  index 
files  could  be  used. 


Figure  16.  Data  Base  Query  File  Logical  Design. 

Tne  data  base  query  file  would  be  loaded  into  main 
memory  eacn  time  tae  Query  module  is  activated.  Tnere  is  no 
requirement  tcwmwrite  tae  file  to  secondary  storage  wnen  tne 
Ouery  module  is  deactivated  since  tnere  will  be  no  caanges 
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male  to  tfte  file.  In  mat  tne  Query  moauie  and  tne  data  base 
query  file  rfouid  be  simultaneously  located  in  main  memory, 
queries  could  ee  quicicly  and  efficiently  processed. 

Tnis  eliminates  tne  need  to  access  tne  dlsic  to  perform 
queries,  tnerefore  greatly  reducln?  tne  processing  time.  Tne 
cost,  nowever,  is  in  an  additional  file  in  secondary 
storage,  an  array  to  noli  the  data  base  query  file  in  main 
memory,  redundancy  of  data  and  tailoring  of  tne  data  base 
query  file  and  the  Query  module  to  fit  into  main  memory 
simultaneously.  There  is  also  tne  added  complexity  to  tne 
program  when  additions,  deletions  and  changes  are  made  to 
tne  main  file  in  tnat  tnese  cnanges  must  also  be  reflected 
in  tne  data  base  query  file. 

Consideration  was  given  to  doine  all  updates  to  the  data 
base  query  file  wniie  it  was  located  in  main  memory  since 
the  array  which  holds  tne  records  is  a  static  data 
structure.  While  it  would  improve  system  efficiency  and 
preclude  loading  tne  data  base  query  file  each  time  tne 
module  was  called,  tne  cnances  of  loss  of  lata  tnrougn  a 
power  surge  or  a  system  failure  are  sufficiently  great  to 
eliminate  this  approach.  Tne  differences  between  tne  two 
data  files  after  a  long  period  of  uninterrupted  operation 
would  render  tne  query  capabilities  invalid’  because  of 
inconsistent  data.  The  expected  configuration  of  the 
allocation  of  main  memory  during  data  base  query  operatiors 
is  snown  in  figure  17. 
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Figure  17.  Main  Memory  Map  For  Data  Base  Cueries 


While  each  of  tne  above  alternatives  supports  the 
logical  deslen  of  the  data  base,  the  third  alternative  is 
tne  fastest  and  was  selected  because  of  tne  user's  need  for 
timely  access  to  tne  data  base  informatioi.  Tne  expensive 
trade-off  in  added  complexity  and  redundancy  is  made  in 
favor  of  tne  user. 

4.  Inverted  File  Design  Considerations 

An  inversion  on  tne  secondary  keys  would  allow  tne 
system  to  conduct  multiple-key  orocessine  of  queries.  Earn 
of  tne  secondary  keys  would  nave  a  separate  inverted  file 
for  each  of  the  values  of  tneir  domain.  The  index  would 
contain  tne  actual  pointer  to  tne  appropriate  record  in  tne 
data  base  query  file.  An  example  of  an  inverted  file  for  the 
target  priority  attribute  is  snown  in  figure  18. 
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Tarsfet  Priority  Index 


Figure  13.  Example  of  an  Inverted  File  Lo«ical  Structure. 

The  implementation  of  me  inverted  files  couia  employ  a 
United  list  of  tne  target  location  pointers  oy  specific 
domain  of  the  attrihute.  However,  this  file  must  be  updated 
each  time  tne  user  adds  or  deletes  a  target  from  tne  system 
as  well  as  maices  a  specific  chantfe  which  will  affect  the 
index.  For  example,  a  priority  I  target  could  be  cnangea  to 
a  priority  17  tareet  after  successful  attacic  by  supporting 
arms.  Tnis  would  necessitate  a  cnange  in  tne  main  target 
file,  tne  data  base  query  file  and  tne  inverted  index  for 
target  priority  (both  for  priority  I  and  I7^  as  well  as  an 
input  for  tne  transaction  log  of  the  TARBUL. 

This  disadvantage  combined  with  the  complexity  of 
implementing  United  lists,  maintaining  multiple  inverted 
index  files  and  the  overhead  Involved  detracts  significantly 
from  tne  elegance  of  using  inverted  files.  A  simple, 
practical  and  straight-forward  solution  Is  required. 
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6.  Flat  File  Array  Processing 

The  data  base  query  file  is  implerpentel  as  a  single 
dlTjension  array  of  records  so  mat  it  can  be  ioadea  into 
main  memory.  Tbe  OCSD  Pascal  system  performs  effective  array 
processing  and  tnis  feature  can  be  used  to  perform  me  data 
base  4uery  functions.  Tfte  metnod  selected  for  tce  target 

r- 

information  system  is  array  processing  of  tne  flat  fixe. 

T&e  Query  module  prompts  the  user  to  select  the  special 
criteria  for  tne  target  listing.  It  does  tnis  by  presenting 
the  user  a  series  of  menus  from  which  the  secondary  Keys  and 
tnelr  respective  domain  attributes  can  be  selected.  Once  me 
attribute  is  selected,  the  module  processes  the  array  to 
determine  if  tne  targets  in  the  array  possess  this 
attribute.  Sacn  target  with  tne  attribute  is  flagged  and  tne 
system  returns  to  tne  menus  for  furtner  Key  selection.  A 
domain  can  be  selected  only  once  per  list.  Thus,  tne  system 
permits  only  tne  logical  ’’andING"  of  one  attribute  of  tne 
domains  of  tne  secondary  Keys. 

Upon  selection  of  another  attribute,  the  system  will 
process  only  tae  targets  which  were  flagged  oy  the  previous 
array  processing.  This  will  significantly  reduce  the  search 
time  and  result  In  increasingly  greater  refinement  of  me 
list  for  each  subsequent  part  of  the  query.  Since  there  are 
only  six  secondary  Keys,  tne  maximum  query  size  is  six  items 
although  tne  user  could  stop  snort  of  that  number  at  any 
time  in  tne  processing.  Wnen  me  user  stops  tne  query  and 
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requests  tne  listing,  tnose  targets  wnicti  are  fiagges  are 
accessed  and  written  to  tne  console  screen.  Wnen  tne  next 
query  is  initiated,  all  tne  flags  are  reset. 

Two  additional  design  features  nave  oeen  incorporated  to 
speed  tne  array  processing.  Tne  first  feature  is  tne  storage 
cnaracteristics  of  tne  seconaary  ^eys  in  tne  record.  Eacn  is 
stored  as  a  single  cnaracter  requiring  no  type  conversion 
tnus,  enabling  quiet  ana  easy  comparisons.  Tne  second 
feature  is  in  tne  design  of  tne  query  menus. 

The  menus  nave  been  arranged  sc  tnat  tne  most 
discriminating  indices  are  presented  to  tne  user  first. 
Tareet  type  nas  a  domain  of  nine  values  and  is  presented 
first  to  tne  user.  Tnus,  tne  first  pass  at  tne  target  list 
will  probably  result  in  tne  smallest  list  of  flagged 
targets.  This  reduces  the  amount  of  array  processing  for  the 
remaining  portions  of  tne  querv.  For  example,  if  tne  system 
nas  10J}  targets  and  92  of  tnese  are  "active"  status  and  14 
are  of  type  "tanit",  tnen  tne  first  pass  in  eitner  case  will 
be  for  all  100  targets.  If  status  was  the  first  part  of  the 
query  tnen  tne  next  search  would  be  through  82  "active" 
targets  until  the  "tanii”  targets  were  found.  However,  if 
type  was  tne  first  part  of  me  query,  only  14  records  of 
type  "tantc"  would  nave  to  be  searched  to  find  the  "active" 
targets.  Tne  first  searen  processed  192  targets,  tne  second, 
using  tne  least-list  principle,  processed  only  114  targets. 


Ttie  ptiyslcal  design  of  tne  lata  base  query  file  is  snon/n 
in  figure  19. 
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Figure  19.  Data  Base  Cuery  File  Pnysical  Design. 

5.  Data  Base  Partitioning 

In  addition  to  tne  main  target  file  and  tr.e  data 
base  Query  file  addressed  above,  tne  functions  of  tne  system 
require  additional  file  considerations.  In  particular,  tnere 
is  tne  requirement  to  produce  a  TAHBUL  «nen  requested  by  tne 
TI3.  Tne  system  must  retain  in  a  separate  file,  aii  tne 
information  tnat  is  appropriate  for  tne  TAHBUL.  Typically, 
tnis  information  consists  of  targets  added  to  or  deleted 
from  the  tareet  list,  cnanees  to  targets  on  the  tareet  list 
and  significant  BDA  on  attacied  targets.  Tne  Target  module 
Of  tne  applications  program  extracts  and  formats  tne 
appropriate  information  for  tne  TARBUL  file  in  conjunction 
with  normal  processing. 


A  securiir  feature  of  tne  system  is  a  user  aefitiei 
password  wiiicQ  aiicws  entry  into  me  program  only  wnen  tne 
proper  password  nas  been  received.  In  order  to  provide  for 
tne  retention  of  passwords  between  uses  of  me  system,  a 
small  file  was  constructed  wnicn  contained  tne  user 
password.  A  procedure  of  tne  system  allows  tnis  password  to 
be  written  to  tne  disJcette  and  retrieved  wnen  tne  system  is 
activated. 

Tnere  is  a  requirement  to  provide  tne  user  witn  a  file 
status  report  on  a  periodic  basis.  It  is  essentially  a 
statistical  breakdown  giving  tne  number  of  active  targets, 
Inactive  targets  and  targets  on  tne  target  list  as  weii  as  a 
count  of  me  targets  in  eacn  attribute  by  domain.  A  separate 
file  could  be  sept  for  tnis  information,  but  to  decrease 
complexity  and  storage  requirements  for  tne  system,  a 
routine  from  tne  Utility  module  is  used  to  accumulate 
statistics  from  tne  data  base  query  fils  and  display  me 
information  to  tne  CRT  screen  wnen  reouestel  by  tne  user. 
Once  again,  naving  tne  data  base  query  file  in  main  memory 
will  reduce  tne  '•omputation  time  needed  for  tnis  process. 

Tne  data  base  is,  tnus,  partitioned  into  two  data  Ease 
riles  (one  a  subset  of  tne  otner)  and  two  utility  files,  me 
TARBUL  file  and  tne  password  file.  Tney  must  snare  secondary 
storage  space  witn  routines  or  tne  operating  system  and  tne 
applications  program  object  code.  Tne  partitioning  or  tne 
data  base  is  depicted  in  rigure  . 
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Figure  2i!.  Data  Base  Partitioning. 


D.  OTHER  CONSIDERATIONS 

In  considering  inverted  flies,  it  was  deterT.ined  tftat 
sone  record  attricutes  did  not  yield  a  sufficientiy 
discriminating  index.  For  example,  tne  data  item  "status" 
yielded  a  poor  index  since  only  two  values  are  possicie, 
active  and  inactive.  In  an  effort  to  estaniisn  more 
discriminatory  indices  and  at  tne  same  time  reduce  me 
pnysical  size  of  tne  data  items  in  a  record,  index  items 
were  combined  and  compressed  in  a  coded  form.  Target  status 
was  enlarged  to  encompass  tne  target  list  index  and  tne 
target  attacKed  index.  Tne  combining  of  tnese  tnree  indices, 
eacn  witn  domains  of  value  two,  yields  one  incex  witn  a 
valid  domain  of  six  values.  Tne  newly  formed  index  is  as 
follows : 
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The  lata  llctionary,  which  was  leveioped  in  response  to 
the  volume  analysis  of  tne  lata  case  recori,  addresses  eacn 
attribute  separately  by  name,  data  type,  physical  size, 
logical  size  and  lists  the  domain  wnere  appropriate. 
Specifics  about  the  tareet  record  and  the  query  record  are 
listed  as  well  as  a  determination  of  the  physical  record 
size.  Ail  tne  data  in  tne  record  is  in  ASCII  character 
format*  even  items  sucn  as  tne  grid  location  ana  altitude, 
Which  are  actually  integer  values,  are  stored  as  characters. 
Conversion,  wnen  necessary,  is  performed  by  tne  applications 
program. 

£.  SUMMAfif 

The  primary  consideration  in  tne  design  of  tne  data  base 
was  ease  of  use  ana  speed  for  tne  user  in  me  microcomputer 
environment.  Tnis  consideration  overrides  tne  inefficiencies 
of  a  dual  data  base  record.  Moreover,  the  complexity  of  me 
processing  requirements  is  invisible  to  tne  user.  Ke  is 
concerned  only  with  fast  retrieval  of  certain  types  of 
information.  As  tne  casual  user,  ne  is  not  concerned  witn 
nieh  level  query  lan«rua«es  and  tneir  use.  Rather,  ne 
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re;iuires  a  Tiacalne  tnat  wiii  serve  nls  needs  ana  not  tne 
otner  way  around. 

£.  F.  Codd,  in  nis  1^74  arilcie  Seven  Sieps  lo 
Rendezvous  wlih  me  Casual  Oser  staled  mat  "it  is  proje^'ied 
mat  by  me  turn  of  me  century,  me  majority  of  data  base 
manaeement  systems  will  be  oriented  toward  me  ''asual  user’  . 
A  system  wnicn  will  oe  able  to  perform  its  function  quicsiy, 
easily  and  accurately  during  tne  intensity  of  combat 
operations  will  be  me  one  mat  is  specifically  desli?ned  to 
conform  to  tne  user's  environment.  Tnis  system  was  desi^^nsd 
witn  mis  principle  in  mind. 

Tne  following  cnapier  describes  me  important 
considerations  of  me  user  interface  and  me  metnoaoloey 
employed  in  masing  tnis  interface  an  effective  one.  It 
considers  me  psycftolosicai  issues  wtticn  affect  me 
maa-macnine  interface  as  well  as  me  modes  of  user  input  and 
computer  initiated  dialogue.  Tnese  are  me  tecnniques  wnicn 
enable  me  target  information  system  to  conform  to  me 
user's  environment. 
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I.NTEHACnVl’  UTEaJACz,  DESIGN 


A.  GENERAL 

One  of  tne  major  aesien  features  of  tne  tareei 
information  srstem  is  tnat  it  provile  a  friendiy  yet 
sopnis r.i ca ted  user  interface.  It  s-nouici  oe  sufficiently 
sopnlsticatsa  to  perform  axi  of  tne  reuuirea  functions 
simply  and.  efficiently  wltn  only  a  minimum  of  interaction 
from  tne  user.  Tne  environment  must  be  a  friendly  one, 

allowing  tne  user  to  recover  gracefully  anct  witn  mininum 
effort  from  error,  ffuiaine  tne  correct  input  am  providinff 
tne  user  witn  assistance  or  information  wnen  needed. 

Tne  user  is  a  Marine,  trained  in  tne  conduct  of 

supporting  arms  operations  in  a  comoat  environment.  He  is  a 
parametric  user,  a  casual  operator  of  a  computin^r  macnine, 
witn  no  computer  training  ana  a  limited  capaciiity  nf 

operating  a  computer.  Tne  system  must  be  sufficiently  simple 
for  tnis  ussr  to  learn  to  operate  it  effectiveiv  in  a 
■minimum  of  time  and  witn  a  minimum  of  effort.  It  must 

inspire  nis  confidence,  simplify  nis  tass,  increase  ms 
effectiveness,  reduce  or  eliminate  any  computer  "anxiety" 
and,  most  importantly,  enable  aim  to  accurately  ana  ouiciriy 
carry  out  nis  mission. 

This  cnapter  outlines  me  design  criteria  ana  tecnnioues 
used  in  determining  tne  quality  of  tne  man-macnine 


interf'5ce.  Tnese  criierla  were  erpioyei  in  me  design  oi  me 
applications  program  and.  constitute  its  tasic  rranewori.  Ine 
syste.'n  effect! venesi  can  only  ce  measurel  oy  now  well  tne 
interface  oetween  me  nen  ana  tne  macnine  nas  succeeaea. 
Jares  'Martin,  in  nis  Design  of  '^,an-Corputer  Dialogue 
described  tne  psycnoiogicai  i^ipaci  of  tne  interactive 
interface  cn  tne  user  as  follows: 

"it  nas  oecome  increasingly  realized  mat  rcany 
information  processing  operations  are  eest  carried  out 
not  by  macnine  alone,  nor  oy  man  alone,  out  by  a 
judicious  comoination  of  man  and  macnine...  A  itey  to 
success  in  many  real  time  operations  lies  in  tn“ 
recognition  of  macnine  limitation  and  tne  ouiidine  into 
tne  system  of  appropriate  numan  capaoiiities." 

S.  DESIGN  PRINCIPLES 

Tnere  are  four  oasic  principles  used  in  tne  design  of 
tne  user  interface.  First,  it  must  oe  self -erplanatcry .  Tne 
user  must  be  able  to  use  tne  system  wiinout  reference  to  an 
external  source.  Tnis  implies  mat  tne  system  guice  ana 
direct  tne  user  in  tne  execution  of  nis  lasics  regardless  or 
nis  level  of  expertise.  Tnis  requires  simplicity,  ease  of 
use,  and  elimination  of  system  failure.  Second,  tne  system 
must  be  self-nelping .  Waenever  tne  user  wants  or  reuuires 
nelp  or  assistance,  me  system  must  respond.  It  snouii 
identify  tne  improper  input,  guide  me  user  to  me  crcper 
input  required  and  provide  an  example  or  tne  correct  input 
wnen  appropriate.  Accordingly,  error  messages  must  re 
explanatory  and  me  system  must  respond  to  every  input. 


Tne  tnira  principle  is  a  requirement  for  a  simple 
interface  wi tn  tne  user.  Tne  system  must  respond  in  a  timely 
fasnion  to  input  wnicn  is  snort,  simple  ani  oovious  to  tne 
user.  Tne  processing  complexity  must  oe  invisioie  to  tne 
user  for  every  procedure  of  tne  system.  Iney  snouia  all 
appear  to  oe  a  straignt-f orwarc.  and  simple  tasi. 

Tne  fourin  principle,  previously  mentioned  in  Cnapter 
III,  is  interaction  oy  anticipation,  tnat  is,  anticipating 


tne 

desi  res 

of 

me  user 

and 

presenting  nim 

w  i  t  n  a 

corresponding 

list 

of  options. 

Tnus , 

tne  system  can  avoid 

tne 

pro  olems 

Of 

employing 

erro  r 

diagnostic  and 

advisory 

messages.  Only  tnose  actions  mat  are  legitimate  are 
presented  for  user  selection.  Input  of  any  of  tne  displayed 
actions  will  result  in  a  syntactically  correct  command  ana 
allows  furtner  processing.  Input  of  an  action  otner  tnan  tne 
legitimate  one  results  in  a  simple  user  advisory  message  ana 
ODviates  tne  need  for  elaoorate  liaenosti-'s .  Ine  most  •'ommon 
type  of  dialogue  tnat  uses  interaction  oy  anticipation  is 
menu  selection  and  to  a  lesser  degree,  form  riiiing.  '^enu 
seiectlon  allows  tne  user  to  select  me  deslrea  option 
ratner  tnan  requiring  nim  to  specify  tnat  option. 

C.  PSYCHOLOGICAL  ISSUES 

1 .  Snort-Term  nemory  Considerations 

Our  SQort-terrr  memory  noids  interpreted  units  of 
information  for  up  to  seconds  oefore  it  fades  away.  Vitn 


cociinuei  exposure  lo  tne  sare  type  of  iLformaticn, 
sr.on-terTi  -rienory  retention  can  re  irprovea  out  essentiaiiv- , 
*e  are  aoie  to  retain  only  a  iii^ited  amount  of  information 
at  one  time,  ieorge  Miller's  classic  paper  in  iyS:c,  Tne 
Magical  Nutroer  Seven — Pius  or  Minus  Two,  lescrioel 
experiments  wnicn  suggested  tnat  tne  snort-term  memory  was 
limited  to  a  perception  of  aoout  seven  units.  For  terminal 
interaction,  tnis  implies  tnat  tne  processing  capacity  of  an 
individual  is  limited  to  only  a  few  items  and  tnat  it  snouid 
be  tatcen  into  consideration  wnen  designing  menu  formats. 
Tney  snouid  be  simple,  semantically  meaningful,  arranged  in 
a  logical  progression  (to  tne  user. ..not  tne  programmer)  and 
brief . 

2.  Closure 

Tnsre  is  great  psycnoiogical  relief  to  snort-ier-ri 
memory  wnen  information  no  longer  needs  to  oe  retained.  Tnis 
produces  a  powerful  desire  to  complete  a  tasi  witnin  tne 
snort-term  memory  span,  reduce  tne  memory  load  and  ^ain  tne 
psycnoiogical  relief.  Closure  is  tne  completion  of  a  tasi 
leading  to  tnis  relief.  Tne  user  expects  to  experience 
closure  after  compleiirg  an  activitv.  Any 'delay  in  acnieving 
closure  or  tne  interruption  or  tnis  process  is  frustratins. 

Tne  pressure  for  closure  implies  tnat  tne  user 
(particularly,  tne  novice  or  parametric  user)  will  prefer 
multiple  small  operations  ratner  tnan  one  large,  complex 
one.  In  system  design,  tnis  suggests  tnat  interactions  ce 
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aerinei  in  sections  or  logicai  segments  so  mat  coTioietion 
C5n  pe  oPtair.el  ani  information  released.  Ail  actions  of  tne 


user  snouia  te  responded  to  in  a  positive  manner  07  tne 
system. 

6,  User  Anxiety 

Tne  user  attitude  toward  tne  computer  can  impact 
upon  nis  learnin?  ana  performance  **itn  tne  system.  Computer 
"anxiety",  generated  oy  fear  of  failure,  may  reduce  tne 
user's  snort-tren  memory  capacity  and  innicit  nis 
performance.  Tne  system  snouid  put  tne  user  at  ease  out 
witnout  oein?  patronizing,  obvious  or  cute.  Tne  user  will 
respond  better  if  tne  instructions  are  clear,  unamDi*ruous , 
expressed  in  familiar  terms  and  easy  to  follow.  Constructive 
advisory  messages  and  positive  reinforcement  are  prefered  to 
inreatenine,  condemniaff  or  meaainffiess  error  messages, 
"please  reenter  your  cnoice"  is  more  user  friendly,  less 
intimidatine  and  more  effective  tnan  "jiad  entry-error  . 

Tne  target  information  system  nas  been  designed  to  provide  a 
comfortable,  nelpful  and  friendly  environment. 

4.  Control 

A  driving  force  in  numan  nature  is  tne  desire  tc 
control.  In  using  computers,  tne  novice  is  perfectly  willing 
to  follow  tne  computer's  instructions  ann  accept  tne 
computer  as  tne  controiiiaff  a^ent  in  tne  interaction.  As  nis 
level  of  experience  increases,  tne  user  may  resent  tne 
computer's  dominance  and  may  Iook  at  tne  computer  only  as  a 


tool.  Taus.  tae  system  snouia  ce  aesi^aea  to  er.aaace  tne 
user  coatrci  or  at  least  tae  appearance  cf  user  ccntrci. 
Properly  lormattea  means,  aavisory  messages  ana  error 
lia^nostics  car.  ?ive  tae  user  tae  impression  tnat  ae  is  in 
complete  control  of  tne  situation.  Tae  menu  allows  air  to 
maie  decisions  on  input  parameters  as  weii  as  selecting 
different  i unctions. 

D.  iinSPC'NSii;  Tlr^K 

A  Simple  limit  on  response  time,  tae  time  it  ta/ces  fcr 
tae  system  to  respond  to  a  command,  is  desiracie  for 
effective  man-macnine  interface.  An  acceptaoie  response  time 
is  3  function  oi  tne  type  of  command  ana  tae  user's 
expectation  of  wnat  a  reasonaoie  response  time  is.  for  some 
operations,  ae  is  content  to  let  tae  macniae  crua'^n  a«ay  cut 
for  otaers,  ae  expects  an  immediate  response.  Tae  tlmeiiaess 
of  response  to  target  information  queries  was  tae  primary 
factor  for  tne  design  of  tne  auai  aata  case. 

In  normal  conversation,  tae  user's  expectancy  or  a 
response  is  wltnin  aoout  two  seconds.  A  lacic  of  response 
witnin  four  seconds  would  Oe  an  unnatural  Dreajt  in  me 
conversation.  In  studies  of  man-macaine  interface,  a 
response  witnin  two  seconds  aas  neen  snown  to  constitute  an 
important  and  reasonaoie  oouadary  in  tne  effectiveness  of 
feedoacic.  Errors  must  oe  responded  to  witnin  two  tc  fcur 
seconds  so  tnat  tne  closure  period  is  forced  at  tne 
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appropriate  time.  «aiie  syste:n  iPi  ta  li  za  tlon  Tay  ce 
acceptable  to  toe  user  witrir  iii'  secoras,  ne  experts  to 
access  tne  next  rtenu  or  to  receive  input  neip  axncst 
instantly.  *inen  tne  aeiay  is  expectea  to  sxceea  tne  two 
secona  para-neter,  tne  systeti  snouia  actcnowieage  tne  connana 
anl  inaicate  tnat  processins  is  unaerway  (ana  perioaicaily 
reinforce  tnis  until  tne  process  is  complete;.  Tnis  ensures 
tnat  tne  user  snows  nis  ccmmana  nas  been  acneptea  ana  me 
macnine  is  processin^^'  tne  request  ratner  tnan  observing  a 
mans  screen  ana  wonaering  wnat  to  ao  next. 

il.  INPUT  yorES 

1 .  Voge  Selection 

Amon?  tne  airrareat  types  or  interactive  liaio^ues 
considered,  computer  initiatea,  form  fiiiin^r  ana  menu 
selection  were  aeterminel  to  oe  me  most  appropriate  for  me 
oarametric  user  ana  tne  specific  application  of  tar?et 
information.  A  combination  of  tnsse  tnree  metnoas  prcviaes 
flexibility,  ease  of  use,  simplicity  ana  covers  a  complete 
range  of  tne  system  functions. 

Tne  computer  initiatea  aiaiogue,  wnere  tne  user  responas 
to  tne  computer,  nas  tne  aavantage  or  requiring  very  iittie 
training  for  tne  user  to  operate  tne  system.  However,  tne 
aiaiogue  can  oe  ratner  len^ftny,  tne  system  can  ce  ratner 
slow  to  respond  and  tnere  is  a  loss  of  flexibility  in  tne 
sequence  of  ttie  lialoeue.  Tne  form  fiiiine  tecnnique,  wnere 


trie  user  fills  out  for^i  on  a  visual  aispiay  aevice,  is 
strsigf.t  icrwarl  for  tne  operator  in  tr.at  all  ne  needs  to  lo 
IS  provide  tne  appropriate  inforiiati  on .  Error  diagnosis  must 
oe  im-nediate  to  oe  effective  and  cursor  manipuiaticn  must  oe 
considered . 

!^enu  selection,  wnere  tne  user  selects  an  appropriate 
response  to  a  numoer  of  cnoices,  requires  little  or  no  user 
training  and  nas  tne  advantage  tnat  tne  user  may  ce  informed 
aoout  tne  full  range  of  tne  system  features.  A  simple  exit 
from  tne  menu  sequence  and  tne  opportunity  to  return  to 
previous  menus  enables  tne  user  to  acnieve  flexibility  to 
navigate  inrougn  tne  system.  Tne  limited  number  of  cnoices 
on  any  particular  frame  and  tne  information  about  tne 
sequence  of  frames  wnlcn  leads  to  tne  current  one  provide  a 
narrow  context  witnin  wnicn  it  is  easy  to  design  effective 
user  aids  and  error  messages. 

Menu  selection  is  a  form  of  computer  initiated  dialogue 
since  it  Is  asrin^  cne  user  a  question  and  proviiins  a 
limited  set  of  valid  answers.  Tne  user  determines  me 
appropriate  input  and  tne  system  responds  witn  tne  answer  or 
anotner  menu.  Tnis  contributes  to  tne  ease  of  use  of  tne 
system  and  tne  untrained  user  can  become  proficient  in  a 
very  snort  time.  Tne  tecnnique  does  run  me  risx  of  oeir.e 
too  slow  and  tedious  out  it  can  be  speeded  up  by  a  nign 
speed  terminal  and  fast  access  to  menus.  Figure  iil  is  an 
example  of  a  menu  from  tne  target  information  system. 

lk:b 
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Tne  -nanner  in  waicn  me  aata  is  fonnatied  can  affect  me 
efficiency  of  tiie  operator  oy  infiuencinij  bom  nis  speed  and 
nis  error  rate.  A  poorly  formatted  diaiot^ne  car.  cause 
bewi laerment ,  anxiety  and  improper  input.  James  Martin  1  r. 
nis  boolc.  Design  of  ^an-Computer  lialogue.  lists  t-elve 
criteria  for  tne  design  of  menu  ani  form  filling  screen 
formats.  These  criteria  were  used  in  tne  d=si-?n  a-ci 
impiementatl on  of  tne  target  information  system: 

1.  Display  a  smaii  amount  of  information  at  one  tire 

2.  Do  not  include  unwaniea/unneeded  information 

3.  Have  one  idea  per  display 

4.  The  operator  response  snouli  be  snort 

5.  Tne  computer  snouia  always  respond  to  tne  operatcr 

5.  Use  formats  desienei  for  clarity 

7.  Strive  for  similarity  'position,  format,  terms) 

3.  Avoid  difficult  words  or  cnaracters 

9.  Provide  an  easy  means  for  correction 

13.  '^aie  instructions  to  tne  operatcr  stand  out 

11.  Clean  up  the  screen  wnen  pcssitie 

12.  .''a.'Ce  it  easy  for  tne  operator  to  asi  for  help 

S.  E.  Enele  and  K.  E.  Crania  in  their  worii,  G ul del  1  ne s 
for  Mar./Display  Interface,  mention  many  different  and  useful 
techniques  for  improvins  the  interactive  dialogue  and  tne 
user  input.  Some  of  tne  more  important  points  used  in  tne 
desian  of  the  target  information  system  are  paraphased  in 
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tne  foliowiag  list  : 

A. vole,  a t ore d1  at i ons  ana  coc tract iens 

5e  consistent  in  use  ana  .Tieaain*?  of  tecr.nlcai  woris 

Use  exanpies  to  suppietient  Inst ructi or.s 

3e  consistent  in  presenting  iden ti ca i /s inilar  data 

'Jse  nunbers  wnen  iistlnr  seieatacie  ite~s 

Place  most  prooaoie  itecis  at  tn^  top  of  tne  renu 

Standardize  screen  organization  and  ferret 

Sive  user  directions  before  tne  list  of  cnoioes 

User  input  snouid  be  icept  to  a  (ninimur' 

Present  data  in  a  recosnizabie  order 
Avoid  verbosity  ana  wordiness 

?.  EKHOS  HANDLING 

Weil  designed  aiaenostics  and  error  nsssa^es  can  f'uide 
tne  user  to  enter  tne  correct  ccrioianas.  Uner.  tne  systert 
prooipts  tne  user  tnat  An  error  nas  occurea,  it  snouid  aiiow 
for  error  correction  itinecia teiy .  In  tne  menu  selection 
dialogues,  tne  range  of  options  is  preaetermined  tv  tne 
system  and  only  a  valid  input  will  result  in  tne  appropriate 
closure.  Invalid  inputs  can  be  -easily  determined  and 
appropriate  guidance  provided  to  tne  user  in  tne  error 
message  to  obtain  tne  proper  input. 

form  filling  dialogue  can  cnecjc  tne  field  len<rtn  ana 
field  type  (for  example,  a  grid  location  would  consist  rf 
eignt  numbers  and  any  otner  input  would  be  invalid).  Error 
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71 1  APPLICATIONS  P'X&HA^  I'-F]^>.mvv^5^IC«; 


A.  STSTE,'"  I^^PIEySNTATION 

P^sed  on  me  i9Si!?n  criteria  ouiiir.ei  in  'rCapt^rb  17. 
and  71,  tne  target  informatior  systea;  was  cccer!,  ci’i'^plie 
and  tested.  Each  froaule  was  coded  inaependent iy  oi  rne  ctne 
ann  tested  ir.  its  own  envi  rcHTent .  Siriiarity  c:‘  tr. 
interface  oas  Taintainel  between  eacn  rcduie  and  was  tr 
first  part  of  eacn  module  coded.  After  tne  interface  was  i 
place  and  worcins,  tne  module  was  filled  out  to  perforr  tr 
systen  functions.  After  eacn  module  was  tested  and  detufc'e 
independently,  it  was  incorporated  into  tn?  syste'"  wre: 
additional  testing  and  debugging  tooi  place.  Tne  nett  Tiodui 
was  tnen  coded  after  tne  system  was  functioning  properly. 

Tne  Interface  moauie  is  tne  main  system  program  an 
contains  tne  global  aata  structures  ana.  tne  syst"=rr.  pri"itiv 
routines  sucn  as  clearing  tne  screen,  sKipping  lines,  an 
printing  error  messages.  It  maies  tie  cdils  to  tne  Srg-'‘=n 
procedures  from  a  r»;abter  menu.  Anotner  primary  function  c 
tnis  module  is  to  ouxia  tne  aalress  map  of  tne  reccrns  a 
tne  start  of  eacn  session  and  to  open  tne  systen  data  fii“S 
Tnis  module  complied  to  bytes  of  object  cone  »nicn  i 

four  S  less  tr.an  originally  expected. 

Tne  first  of  tne  segment  routines  is  tne  Inform  monuie 
Tnis  module  contains  system  operatine  ins; rur ciors 


ioctrlnai  explanation?  of  target  infornaiior;  ler^?,  tar^'St 
analysis  euifeiires,  senurity  re^ui  reTippts  arn  exarpips  cf 
fomats  used  in  tnp  syster.  It  is  tasioaiiy  all  text  anl 
serves  to  inform  tne  user  of  tn?  capaoilities  of  tne  system. 
Tne  module  oomplles  to  bytes  of  object  code. 

Tne  Initialize  module  is  designed  to  erase  tne  current 
data  files  and  completely  reinitialize  tne  syste-".  It 
performs  no  otner  function  for  tne  system.  It  cuilns  tne 
lata  files  to  tre  reouired  size  and  fills  tne  file  witn 
empty  records.  It  compiles  to  25Z«i  bytes  of  object  code. 

Tne  tnirl  seement  procedure  is  tne  Tar,?et  module.  It 
contains  sub-modules  for  aadins  a  target,  deleting’  =  tarp-st, 
cfcansinff  current  tareet  information,  displaying  a  target  and 
ailing  a  3DA  to  tne  target  record,  yajor  dif f  ici:i  ties  were 
encountered  in  loading  tnis  very  large  module  and  its 
involved  user  interface  into  main  memory  witn  tne  operating 
system  cole  and  tne  system  Interface  module.  Initial 
compilation  of  tne  module  was  to  36,42i;  bytes.  Tne  main 
problem  was  tne  amount  of  text  tnat  tne  user  interface  was 
consuming.  One  screen  frame  of  user  information  (advisories, 
explanations,  etc.)  usually  toon  ItTK  bytes  of  object  cols. 
Tne  expense  of  so  mucn  text  in  tne  code  was  mucn  too  great 
for  tnis  module. 

Conseouently ,  a  decision  was  made  to  reduce  tne  size  cf 
tne  module  by  putting  most  of  tne  text  in  separate  text 
flies  on  tne  lissette  and  retrieving  tnese  fixes  from 
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secondary  storage  wner.  caiiea  ov  tne  prceran.  Tnis  produced 
two  unpleasan  t  sia?  effects.  Jirsr,  tae  irt'=Tf5C“  »as  sir  wee 
consiierdCiy  since  it  now  tooic  longer  to  piece  a 
message  on  tne  screen  (aitacu<?.n  tne  user  couid  not  read  as 
fast  as  tne  output'  and  second,  tne  disiette  now  contained 
nunerous  text  flies  in  addition  to  tne  cone  and  data  fiifs 
snown  in  figure  . 

Since  tne  Pascal  systeai  useo  four  ciocKs  of  512  oytes 
eacn  for  a  text  file  no  matter  now  small  tne  file  was,  tne 
54  text  files  tooa  approximately  lliJ  J  oytes  of  secondary 
storage.  This  caused  the  system  to  employ  tne  second  ALTSS 
disic  drive,  wnlcn  nad  not  teen  used  oreviousiv.  Tne 


resui tant 

reconf i^ura lion 

of 

tne 

secondary  storae= 

allocation 

is  snown  in 

figure 

23. 

Certain  menus  and 

recurring  messacas  were  retained  in  tne  tar*ret  modul-  to 
speed  tne  processing  and  decrease  user  wait  time. 

Tne  use  cf  tne  text  files  and  tne  re oreanl 2a t i on  cf  tne 
BDk  routine  into  a  separate  segment  procedure  (called  ty  tne 
Target  segment  procedure},  reduced  tne  module  to  I'^.L'Pr 
Oytes  of  ocject  code  (19,3fe'i:  oytes  when  tee  bZk  prooecure  is 
called).  This  proved  a  satisfactory  solution  witnout  a 
sienificant  deslen  cnange.  Tne  direct  access  capacility  of 
tne  Pascal  system  proved  ootn  accurate  ana  fast  witn  nc 
apparent  wait  in  tne  process  time  cetweea  a  request  for  a 
record  and  a  reply  to  tne  CRT. 
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xi 


T  ^  6 

last 

mo 

iuie  implemented  was 

tne 

Cuery  module. 

It 

empi 0 vea 

some 

of 

tne  menu  text  flies 

used 

by  tne  Targ 

et 

f^olule , 

tnus 

dec 

reaslng  its  code  size. 

and 

proved  easier 

to 

implement 

tnan 

expected.  Wnlie  tne 

query  selection 

is 

limited 

to 

tne 

logical  "andING"  cf  el 

ements  of  tne  donai 

ns 

of  tne  recora,  tne  array  nrocessin?  proved  to  ce  very  rapid 
and  well  witoin  t-oe  two  second  tirre  response  parajieters. 
Loading  of  tne  data  tase  query  file  was  stral^nt  forward  ar.d 
cnanges  In  tne  main  record,  performed  in  tne  tar.^et  module, 
were  beiaf  correctly  reflected  in  tne  data  tase  query  file. 
Vnile  initial  evaluation  of  tde  modUie  proved  satisfactory, 
it  is  felt  tnat  system  improvement  could  te  ootalned  ty 
desi,»ning  an  interface  and  an  algoritnm  wnicn  allowed  totn 
logical  "anEING"  and  "ORING”  of  attritutes.  Tnis  segment 
procedure  compiles  to  oytes  of  otject  code. 

Tne  final  seement  procedure,  tne  Utility  module,  nas  net 
reen  completely  implemented  due  to  programxang  tim.e 
constraints.  Eowever,  tne  complete  user  interfa-'e  is  in 
place  and  operational  and  gives  tae  user  tne  impression  teat 
tne  system  is  operatin®.  Tne  erase  file  function  is 
operational  and  worsts  effectively.  Tne  foliewing  functions 
nave  not  nesn  implemented:  cnan^ine  tne  password  (requires 
design  of  tne  password  recora  as  well  as  implementation), 
copying  tne  data  base  query  and  target  files  to  a  oaesup 
dlsicette,  operations  on  tne  TAR3UL — displaying,  renumbering. 


printing  and  reinitiating  (tnis  also  requires  design  of  tne 


TARBUL  recora),  printing  larp-et  carls  ar.i  lists  ar.J  tne 
"CTiputa  li  on  anl  display  oi  target  file  siaiisti-'s.  Tie 
current  size  of  me  mocuie  is  cvtes.  As  fv:nctions  are 
ailed  anl  tre  size  increases,  rriucn  of  tie  user  interface  can 
oe  transferel  to  text  files  to  teep  tne  size  of  tne  Toiuie 
at  an  acceptable  level. 

Tne  entire  proffrarr  compiles  to  72  R  of  ocject  code,  55 
of  wnicn  is  contained  in  segment  procedures.  Tne  system 
source  code,  <^nicn  is  contained  in  tne  .Naval  Postgraduate 
Scnool  tecnnical  report  entitled  A  Prototype  Prc.eram  for 
Target  Information  ( NPS52-ei-ee7) .  is  over  522’t  lines  ion«-. 
Initial  testing  and  implementation  was  do^e  wiin  a  target 
list  size  of  l£ii  targets  and  later  expanded  to  me  required 
iZd  target  maximum.  It  nas  been  debugged  for  execution  and 
tested  for  operational  accuracy.  .Vniie  initial  results  are 
very  satisfying  anl  me  system  proves  fast  ana  accurate, 
extensive  testing  to  include  field  testing  would  te  reuuirei 
before  tne  system  could  become  operational.  Additionally, 
tne  Utility  module  would  nave  to  oe  coT-pietel. 

Tnere  are  two  main  concerns  in  testing  tne  system. 
First,  tnai  it  meets  me  requirements  of  me  target 
information  section  and  effectively  accompiisnes  its 
purpose. ..  me  automation  of  tne  target  information 
functions,  anl  second,  tnat  tne  user  interface  Is  as 
effective  as  it  proports  to  te.  Tnis  will  require  extensive 
testing  ana  validation  as  well  as  operational  testing  and 


evaluation  in  appropriate  tactical  coTifnanc  post  exercises 
'rfnicn  ejr'ploy  tr.e  livision  or  me  VAB  fire  support 
cooraination  center. 

3.  TECHNICAL  CONSIDERATIONS 

Tne  Pascal  prc^rar  listed  in  tne  tecnnicai  report  is 
transportable  to  otner  UCSD  Pascal  sysierrs  ard  witn 
modi  fi  cat!  on  (random  access,  segment  procedures,  strlce-s'  to 
any  Pascal  system.  Certain  aspects  of  tne  program  were 
irpie-nented  to  conform  to  tne  Datamedia  Elite  ZbCid  viceo 
terminal.  Tnls  terminal  nas  Sid  cnaracters  per  line  wim  ^4 
lines  of  display  witn  full  upper  and  lomer  case  ASCII 
operating  at  a  data  rate  of  'iot’O  baud.  It  nas  a  1920 
cnaracter  screen  capacity,  an  aipnanumeric  Keyboard  ar.d 
display  and  botn  syncnronous  and  asyncnronous  interface. 
Some  of  tne  special  cnaracters  used  in  tne  program  include: 


ASCII 

Decimal 

Junction 

SO 

14 

bilnK  field  on 

CAN 

24 

Diinic  field  of 

BEL 

7 

bell/oeeper 

OS 

29 

roll  field  cn 

OS 

31 

clear  screen 

It  Is  recognized  ttiat  tne  design  and  implementation  is 
based  on  tne  ALTOS  ACS  3000-1  '  computer.  Advances  in 
microcomputer  tecnnolo^y  xlli  invariably  modify  the 
environment  for  wnlcn  tne  prototype  was  designed.  Tne 
addition  of  nard  disi  capabilities  to  microcomputer  syste-^s 


IIT 


T 


will  increase  tne  seconcary  storage  space  as  i*ieii  as  me 
processing  speed  now  avaiiaci®  witr.  floppy  diskettes.  Toe 
current  systen  can  certainly  function  effectively  in  sucn  a 
new  environment  Put  tne  possioilities  cf  redesign  snouid  oe 
considered  if  tne  increase  in  efficienr'y  is  warranted  and 
tne  time  span  between  a  new  implementation  and  tne 
introduction  of  'dllASS  is  sufficiently  lor*;. 

Since  tne  UCSD  Pascal  is  avaliatie  on  so  mar./  systems. 


w i 1 n  tne 

proper  setup  routines  tne 

system  i 

5  suffirientiy 

portable 

provided  tne 

secondary 

s  t  orase 

capability  is 

avaiiabie 

.  Tne  source 

code  is  c 

ompiiatie 

on  personal 

computers 

sucn  as  tne 

Apple  II  wnea  tne  Pascal  system  card 

is  included  witn  a  S-t 

K  memory 

aitnougn 

tne  size  of 

secondary 

storage  (tee 

Apple  uses 

a  5  1/4  : 

nc-.n  mini -floppy 

dissette) 

will  dictate  a 

realignment 

of  files 

c.nd  a  f ur tner 

partitioning  of  system  software. 

C.  TACTICAL  CONSIDERATIONS 

Tnere  are  a  cumber  of  considerations  wnlc.n  involve  tne 
tactical  and  operational  aspects  of  target  information  woi-n 
bear  consideration  out  wnicn  are  beyond  tne  scope  of  mis 
t.nesis.  Tne  first  of  tnese  is  t-ie  survivability  of  tcs  ALTOS 
and  related  equlptnent  in  tne  field.  Special  nanHirr-  and 
care  Is  required  of  eaca  item  as  well  as  tne  system  and 
target  dlsicettes.  Specific  instructions  for  tne  user  in  tne 
maintenance  and  dandling  of  tne  system  must  be  determined 
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anl  proTul^aiel  to  tne  user.  Ailitior.aliy.  iicnev 
re^ul rSTien ts  arl  tne  resultant  e^iuipr^ent  ^loai - 1  catlo r. s  ■'r 
adjustments  resded  to  operate  In  a  field  envlrcnr^nt  must  re 
considered. 

Tne  acaulsition  and  use  of  tr.is  equipnent  may  ce  cause 
to  examine  tn?  tames  of  organization  to  detere'^ir.e  tne 
proper  staffing  of  tne  target  information  section  since  a 
reduction  of  personnel  seems  ratner  =asy  to  acni=ve. 
Additionally,  a  metnod  of  transferlne  data  from  tne  Navy 
ASIS  computer  to  tne  system  microcomputer  snouid  oe 
investieated  and  addressed  since  transferin^  tne  lata 
electronically  between  tne  two  systems  is  preferable  to 
manually  transferin«  tne  lata  into  tne  microcomputer  system. 
Concept  of  employment  of  tne  system  acoard  snip  'in  SACC  or 
in  landine  force  spaces^  must  also  ce  determined  and 
promulgated . 

Once  adopted  and  functional,  icng  ran^e  mans  must  oe 
determined  for  a  transition  from  tne  system  to  tne  "'IFASS 
system.  These,  of  course,  are  locally  c-eneratel  reauirenenis 
and  can  ce  addressed  la  tne  future.  It  is  anticipated  tne 
YiIFASS  will  require  extensive  operator  training  before  it 
becomes  operational  wnereas  tne  microcomputer  pntot,''p= 
system  reouires  only  user  familiarization.  It  is  es.imatei 
tnat  tne  user  can  become  proficient  wltn  tnis  system  after  a 
one  aour  familiarization  period. 


Tne  rs3  ui  rerients  tor  Tainialnir.s  a  ?rapr.i"di  aispidy  cf 
carpets,  wtilie  currently  soivacie  «/itn  computer  ^repnicf, 
will  continue  to  ce  accompiis-^ied  oy  tea  u^e  of  ta-ti-al 
cattle  maps  covered  wltn  acetate  overlays  *r.er£  tr.e 
situation  nictates.  Tnis  system  ma^es  no  attempt  to  accress 
t ns  grapfiic  display  of  targets.  It  is  felt  tnat  tr.e  iiscla/ 
capabilities  of  tne  ylFA.SS  syste-  ^^iil  adequately  satisfy 
me  reQUiremenis  when  tne  system  is  introlU''e'l  into  tne 
fleet. 

D.  STSTE'i  refinements 

¥nile  tne  system  meets  all  tne  reouirements  iientlfien 
for  tne  target  information  section,  tnere  are  a  number  of 
refinements  to  tne  program  wnicn  could  ce  inpie’^ertec  in  a 
later  version  of  tne  prototype  »inicn  would  ennance  tne 
system  performance  and  provide  additional  capabilities  to 
tne  TIO.  Tnese  include  me  following: 

1.  Sxpandlne  tne  size  of  tne  target  file  teyoni  tbe 
current  3ZkJ  target  maximum  if  tne  tactical  conslieraticr.s 
of  future  battle  scenarios  dictate. 

Logical  "oRING”  and  "ANriNG''  of  record  attribute 
domains  in  tne  tuery  module  to  provide  a  more  refined 
selectivity  of  tne  special  target  lists. 

3.  Inclusion  of  a  utility  routine  in  tne  >iuery  module  to 
print  me  tareet  list  obtained  as  a  result  of  tne  query. 
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4.  A.iicw  Tne  user  lo  specify  eitituie  ir.  f^et,  ye  res  :r 
reters  ani  nave  ir.e  sysier  ccnv’rt  tne  iaia  tc  re  tens. 

5.  Find  tne  r.urfcer  and  aesi^naticns  cf  tar-^-eis  wiinir.  i 
certain  radius  or  distance  of  anotner  target  (ter  exa-r-pi’, 
a  class  il  target)  or  a  <nov>n  ^ril  reference  point. 

5.  Provide  a  routine  for  leepin.?  tracit  of  tr.e  next 
available  target  number  from  tne  FFCC  Oioc-c  of  target 
numbers . 

7.  •'Modification  of  tne  TTCSD  Pascal  operating  system 
command  prompt  to  aiiow  tne  user  only  one  •'bcioe  of 
option,  i.  e.,  to  run  tne  systsm  program  and  remove  tne 
filer  subroutine  from  nis  environment. 

B.  Plotting  of  artillery  firin?  units  and  nava:  gunfire 
support  stations  to  determine  automatically,  gnicn  targets 
are  wltnin  tne  effective  rams  of  specific  supporting 
arms. 

y.  Reduction  oi  coding  cy  improved  al?oritr.ma  and 

subroutines. 

IZ .  Provide  operator  training  and  system  maintenenoe 
manuals  for  tne  system. 


liil 


Till  COiNCUSIONS  AND  P.iC  DAT  I  J.\  S 


A.  CONCLUSIONS 

Tnis  inesis  nds  coa  teaiea.  ir.ai  iriS  D?er=  1 1 
5r:'“Ctiver.sss  of  tfie  fire  support  coorainatior.  ce:.ier  *cuaa 
ce  iTjprovea  cy  me  dutoTictior.  of  tae  ta~^'£t  mfo jo 
funcricn.  Furtner,  it  appears  tnat  lae  lesifjn  a-'O 
irplementaii  on  of  a  suitacie  ana.  effective  systerr  is 
pcssiole  now,  five  fuii  years  oefore  tne  introaurtion  of  ine 
yiFASS  coTputer  system  into  tne  Fleet  l^arine  Forcea. 

Tne  tnesis  nas  presented  one  sucn  design  using  a  oata 
oase  approacn  on  a  typically  ^onfi?ured,  commercially 
avaiiacle  microcomputer  witn  a  user  interface  specifically 
lesi^ned  for  me  Marine  performing  tne  target  informiation 
functions  in  an  operational  environment.  An  evaluation  of 
tne  implemented  prototype  '^Icrocompute r  Syste'"  for  Target 
Information  ('^ISTI)  nas  determined  tnat  tne  requirements  ans 
specifications  for  tne  system  as  iescriosn  in  cr.apiers  II 
and  III  nave  oeen  met  and  mat  me  protram  operates 

effectively  and  efficiently. 

Tne  Dasic  soundness  of  tne  lesisn  is  refie''ted  in  ^-ctn 

me  operational  effectiveness  of  tne  prototype  and  tne  laci 

Of  significant  cnan^es  or  modifications  needed  to  meet  the 
stated  system  requirements.  Tne  wording  prototype,  if 

e-rpioyed  in  an  FSCC  in  its  present  state,  «ouid  i '-mediately 
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increase  tr.e  operational  effectiven3';5  of  tne  lar^vet 
1  of  or-'^  ti  cr.  senior.. 

r.  :iicori;.\E.!iriCNS 

Tne  design  anl  iir.piemsn  ta  tion  nas  ceen  snc*r.  to  oe  scnnl 
am,  based  on  me  observed  effectiveness  of  prctct.vpe 

prosraT),  tne  foiioaing  recoTiT.er.dat i  ons  are  naae: 

i.  Tnat  tr.a  i’npierrpr.tat  ion  of  the  prototype  rr  c  corpu  t  e  r 
oyster  for  Target  Information  ('-'ISTI)  ce  continuea  in 
accordance  (i»itn  tne  lesion  criteria  outlined  nerein  and 
tne  system  refinenents  discussed  in  ccapter  VII. 
id.  T.nat  tne  resultant  system  be  tested  and  evaluated  at 
selected  Marine  Corps  commands  to  determine  its 
effectiveness  in  actual  tactical  operations. 

3.  Tnat  tne  Marine  Corps  adopt  t.ne  Microcomputer  System, 
for  Target  Information  (MISTI)  cn  an  interim  casis  until 
tne  introduction  of  tne  '^IFAS^  system. 

4.  Tnat  appropriate  nardvare  and  sofivare  d?  prcvicea  t: 
tre  tnree  Marine  Civision  fire  support  '•oo  rii  na  ti  o  n 
centers  in  order  to  employ  mis  system. 

3.  Tr.at  me  Marine  Corps  Tactical  Software  Support 
Activity  ('^CTSSA)  evaluate  tne  Microcomputer  System  for 
Tareet  Information  (MISTI)  as  a  testbed  model  for  t.ne 
software  interface  criteria  of  tne  target  information 


portion  of  tne  MIFASS  system 


c  y  t  e  5 


I 


I 


; 


A,ttrlcv:tes  ier-r-cn:  42 
Tiiue  sec  Size:  152 
fixed 


Attribute  list: 

(Te 

Target  pe-corn 
rs'et  Cuery  ?.e'' 

and  Tar=;e t 
ord  attribut 

Cuary  Tenorn 
as  inli''atel  t:, 

iTTHIBarS 

».  ^  lw.« 

STjPl'l.'  i G 

I'J 

=5‘TarKet  nu-ncar 

2  cnar.  4  ir.t 

6  cnar 

AA2l‘21-ZZ-J9:4y 

“^Grid  location 

=  int 

c  cnar 

r.u.r  er  i  cai 

=*'A1  ti  tuoe 

^  1  nt 

•i  cnar 

z  1 1 6  ~  y  y  y  y 

"^Desc  ri  pti  cr. 

4t'  Cnar 

4-0  c  n  d  r 
^'^4  :nar 

3  trincj 

P.e-na  rss 

4t  cnar 

4 1'  c  n  a  r 

3 1  r  i  n  s' 

=»Ciassirication 

1  cnar 

1  cnar 

«  r  TN  7 

/It  •st  V* 

’"Type 

4  cnar 

1  cnar 

i  S'  ^  C 

j  \  n 

C?.  TlhF.  ZEr, 

f:r:,  c3»t 

'"rrio  ri  ty 

2  cnar 

1  c  r.  a  r 

1,  II.  Ill,  17 

="Statu5 

2  cnar 

1  cnar 

1  IT  17 2  INACTITE 

"•Supportln?  a 
asslrnea 

4  cnar 

1  CTidr 

AIF,  AFTY.  '-IGF 

^mTT«  % 

^  i.  r...  t  ■'*  ^ 

DIG  surveiii  an-'e 

6  int.  i  cb.ar 

”  cnar 

iiii’ic  iA-2:225y: 

firing  unit 

6  cnar 

5  cnar 

s  t  r  i  r. 

No. /type  rounds 

IZ  cnar 

12  .mar 

5 1  r  i  ;■.  ? 

Dd-nape  assessed 

11  cnar 

1  cnar 

Danaee  reported 

11  cnar 

1  cnar 

Interdict  el. 

neuxraiizea,  liiuTiindtea, 
lardf'ea,  destroyec, 
unicaown,  unotserved. 


13 


APPENCIX  B  -  EXAMPLE  OF  SYSTEM  USER  INTERFACE 


Ttils  appendix  Illustrates  tne  menu  selection  format  of 
tne  user  interface  expialnei  in  detail  la  tne  preceedln^ 
Chapters.  It  simulates  tne  user  operating  the  ^uery  module 
and  forming  a  list  of  targets  for  a  special  listing.  Tne 
fire  support  coordinator  nas  asted  the  target  information 
officer  for  a  list  of  targets  whlcn  are  to  be  considered  in 
tne  formulation  of  a  flat  suppression  fire  plan  prior  to  tne 
calling  of  close  air  support  aircraft  on  an  important 
landing  force  target. 

Essentially,  tne  list  must  include  all  targets  from  the 
following  categories: 

Type . SEAD  targets 

Classification.  ...all  classes 

Priori  ty . I 

Status . ...active  targets 

Accuracy . all  categories 

Supporting  arm ... .artillery 

The  example  simulates  the  user  interface  of  actual 
system  operation  to  complete  tnis  query  as  specified  above. 
Each  page  represents  a  separate  frame  observed  by  tne  user 
on  tne  CRT  screen. 
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SPECIAL  TARGET  LISTINGS 

The  options  are: 

1. 

Forn  a  special  target 

listing 

2. 

Continue  to  process 

3. 

'rfrlte  tne  special  list 

to  tne  Screen 

4. 

Infomatlon  acout  tnls 

procedure 

5. 

Return  to  previous  nenu 

PLEASE 

ENTER  OPTION  NUMBER 

Tae  user  enters  option  l 
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Categories  for  Special  Listing 


The  listing  can  contain  6  Ite-ns  from  me  below  menu 

1.  Tar<ret  type 

2.  Classification 

3.  Supporting  arm  assigned 

4.  Priority 

5.  Accuracy 

6.  Status 

•  P.  Process  information 

Special  list  currently  contains  0  targets. 
Please  start  a  new  listine. 

please  enter  option  number 
*=> 


User  enters  option  l  to  select  tne  tarset  type 


ENTSR  TARGET  TYPE 
Tne  options  are: 

1.  Tank 

2.  SEAD  tareet 

3.  Installation 

4.  Counter  Battery 

5.  Observation  Post 

6.  Terrain 

7.  Venicles 

8.  Fortifications 

9.  Miscellaneous 

PLEASE  ENTER  OPTION  NUMBER 
==> 


L 


User  enters  a  2 


for  tne  SEAD 


targets 
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Categories  for  Special  Listing 

Tne  listing 

can  contain  b  Items  from  tne  oeiow  menu: 

1. 

Target  type  Already  Taiten 

2. 

Classification 

3. 

Supporting  arm  assigned 

4. 

Priority 

5. 

Accuracy 

6. 

Status 

•  P. 

Process  information 

Special 

list  currently  contains  42  targets. 

PLEASE  ENTER  OPTION  NUMBER 
*=>_ 

user  enters  option  3  to  select  tne  supportlne  arm 


L3: 


ENTER  SUPPORTING  AR?1  ASSIGNED  TO  TARGET 


Tne  options  are; 

1.  ARTY 

2.  NGF 

3.  AIR 

4.  AIR,  ARTI 

5.  AIR,  NGP 

6.  ARTY,  NGF 

7.  AIR,  ARTY,  NGF 
e.  Otaer 

9.  None 

PLEASE  ENTER  OPTION  NUMBER 
==>_ 


User  enters  option  1  to  select  artillery 


Categories  for  Special  Listing 

Tne  listing 

can  contain  4  Ite-ns  froti  tne  below  nenu: 

1. 

Tareet  type  Already  Talten 

2. 

Classification 

3. 

Supporting  art)  assigned  Already  Taicen 

4. 

Priori ty 

5. 

Accuracy 

5. 

Status 

*  P. 

Process  infortiatlon 

Special 

list  currently  contains  29  targets. 

PLEASE  ENTER  OPTION  NUMBER 

User  enters  option  4  to  select  tne  target  priority 


ENTER  TARGET  PRIORITY 


The  options  are: 

1.  I 

2.  II 

3.  Ill 

4.  1/ 


PLEASE  ENTER  OPTION  NU'ISfiR 


User  selects  option  1  for  priority 


target 
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Cetegories  for  Special  Listing 


lis  ting 

can  contain  3  ite-ns  from 

tne  oelow 

menu : 

1. 

Target  type 

Already 

Tafcen 

O 

^  • 

Classification 

3. 

Supporting  arm  assigned 

Already 

Taiten 

4. 

Priority 

Already 

Taiten 

5. 

Accuracy 

6. 

Status 

’  P. 

Process  Information 

Special 

list  currently  contains 

16  targets 

PLEASE  enter  option  NUMBER 
==> 


User 


enters  option  6  to 


select 


ttip  target  status 
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ENTER  TARGET  STATOS  —ACTIVITY 
Tue  options  are: 

1.  Active 

2.  Inactive 

PLEASE  ENTER  OPTION  NUMBER  AND  PRESS  RETURN 
«> 


User  selects  option  l  for  active  tar,?ets 
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Categories  for  Special  Listiae 

The  listing 

can  contain  2  items  from 

the  below 

menu: 

1. 

Target  type 

Already 

Taicen 

2. 

Classification 

3. 

Supporting  arm  assiensd 

Already 

TaKen 

4. 

Priority 

Already 

Tajten 

5. 

Accuracy 

6. 

Status 

Already 

Taicen 

»  P. 

Process  information 

Special 

list  currently  contains 

10  targets 

• 

PLEASE  ENTER  OPTION  NUMBER 

User  aas  completed  tae  query  and  now  elects  to 
process  tae  list  of  10  tareets 
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SPECIAL  TARGET  LISTINGS 


Tbe  options  are: 


1.  Fom  a  special  tareet  listing 

2.  Continue  to  process 

3.  Write  tue  special  list  to  tue  screen 

4.  Information  about  tnis  procedure 

5.  Return  to  previous  menu 


PLEASE  ENTER  OPTION  NUMBER 


Tne  user  selects  option  3  to  display  tne  ilstl... 
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SPECIAL  TARGET  LISTIN3 


Categories ; 

SEAD  ACTIVE  Prl 

I  ARTY 

TST  NO 

CL 

PR  I 

LOCATION 

alt 

SA 

DESCRIPTION 

AA^&;46* 

A 

I 

35647582 

100 

ARTY 

2  ZSU-23  PLT 

AA3057* 

C 

I 

35452353 

60 

ARTY 

SA-6  CLUSTER 

AA0078 

A 

I 

35467787 

50 

ARTY 

12.5  AAA  SITE 

AA0156* 

A 

I 

35667746 

120 

ARTY 

S-60  PLT  IN  OPEN 

AA0122* 

D 

I 

35334563 

25 

ARTY 

SA-9  PLT  IN  TREES 

AA0144* 

B 

I 

35674664 

50 

ARTY 

14.5  AAA  SITE 

AA0167 

A 

I 

35455234 

100 

ARTY 

ZU-23  AAA  CLUSTER 

NA0023’*‘ 

D 

I 

34556867 

20 

ARTY 

120  MM  AAA  CANNON 

AA018B* 

C 

I 

34567890 

150 

ARTY 

SA-8  IN  BUNKERS 

AA0194* 

A 

I 

36087546 

45 

ARTY 

S-60  AAA  CLUSTER 

NOTE;  indicates  target  list 


please  press  return  to  continue 


j 


The  user  presses  RETURN  to  continue 
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SPECIAL  TARGET  LISTINGS 


Tiis  options  are: 

1.  Porm  a  special  tareet  listing; 

2.  Continue  to  process 

3.  Write  tae  special  list  to  tne  screen 

4.  Information  about  tais  procedure 

5.  Return  to  previous  menu 

PLEASE  ENTER  OPTION  NUMBER 
«> 


Tae  user  begins  a  new  query  or  returns  to  tne  main  menu 
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